Best Practices for a "Staging" Environment

Hello all!

We currently use our site as a frontend to talk to a backend server, but as we’ve started growing we’ve found a need to start trying to test website changes before pushing them “live” — a mode that isn’t really facilitated through what Webflow natively offers.

We’ve identified that we can publish only to a staging site, but because Webflow defaults to all publish locations being enable, it’s easy for us to accidentally publish staged changes to the “live” site. However, we also need the ability to talk to a different server on the “staging” site, and hence would need to update any custom code that talks to a server. Ideally this can just be managed through the staging site and not have to worry about pushing staging code live.

I’m wondering if anyone has any experience setting up a “staging” environment for Webflow and can recommend some things that have worked for them in the past!

Thanks!

2 Likes

You can’t disable publishing for someone logged in with permissions to publish and publishing means pick the sites, or site you want to publish to.

At the end of the day, it’s really an educational / operational issue. Maybe a short training video would help. Brings back memories of training recruits in class, about a weapon’s safety, and then issues that popped up on the live fire range.

The issue is that all publishing locations are also checked by default, so every time you refresh the page you need to uncheck any undesired publishing locations.

This also doesn’t solve for the need to switch code back and forth to target a staging server or the live server, and exposing that code client side isn’t something that’s desirable either.

1 Like

I wonder if duplicating a project would be a feasible solution?

You could make a wishlist item that webflow should allow you to set a publishing preference other than default, on a project by project basis.

I am not clear of what you want different for the first part of your sentence here. Would you mind elaborating? As to the second part “and exposing that code client side isn’t something that’s desirable either”, I think you can address this currently by publishing to your projecturl.webflow.io site and then unpublishing when you are done testing. That is what I do. You can also change that URL as many times as you want. So unless someone has the new URL they would not be able to see the newly published endpoint.

This is all great to discuss, but unless a wishlist item is made, and voted on, I don’t think it will be on anyone’s radar. The current state seems to be worked for most.

So I’m not that experienced with this but it should be possible to automatic upload files to a GitHub repo. Should something like that solve your problem?

@jorn - using a git repository for exported sites would be a useful way to track changes for all non CMS assets. I do it on my end with a local repo just to keep track of changes over time.

As for automatic ,no , you would just download an export and extract the contents to a local repo. Then push that up to the shared repo. Would be a manual process by a team member.

1 Like

I think this would be possible but the issue is that it’s not programatic — this sort of operation would need to be done daily, if not hourly

I’ll definitely do that as at least one actionable thing.

Imagine I have Server A and Server B. Server A, the “main” server, runs on the master branch of some server code. Server B runs on a staging/development branch of server code. I want to have the ability to have a staging Webflow site always target Server B, and the live site always target Server A. There is a way to do this with custom code where you just check what domain you’re on (staging.mysite.com vs. mysite.com, etc.) and update all your server calls to point to the proper server, but in doing this you potentially expose both your test server’s domain as well as your staging site’s name.

I’ve definitely thought of this as a solution, basically use Webflow’s ability to export a site. I think this would likely be closest to the best possible solution given what Webflow currently offers, and would look like essentially a programmatic way to trigger a site export. Having to manually export/download the site doesn’t scale very well and ideally it could be automated. Then you could have post download hooks that inject the right staging URLs.

1 Like

As another note to this — I feel like the Webflow team proper has to have something similar setup to this or have solved this problem. If the site is really built on Webflow, I highly doubt they only ever use a single master publish and a single server. I would love to know if someone from the Webflow team has any feedback on how they do things.

2 Likes

@depthkit Hey, I am just facing the same dilemma. Were you able to find a work flow to solve stage/qa environment with separate code?

We are having the same issue, and would like to find a solution to this!

Same here. Design, Test, Acceptance and then Production is a process we very much like to stick to, but simultaneous publishing to both staging and custom domain makes that impossible.

I’ve traced back requests for a proper staging environment without the simultaneous publishing to 2016 in this forum. All I see Webflow do is turn a deaf ear. Why is the concept of a staging environment for editors and designers alike such a strange thing to Webflow? What is the philosophy behind that?

1 Like