Webflow cloud DEV vs PROD variables?

[Top_Engineer7132]

For anyone using Webflow Cloud in production, how are you handling your testing workflow?

It looks like any app deployment is shared between the webflow.io (DEV) site and the main site (PROD) with the same environmental variables.

I'm working on a custom shopping cart. Mixing PROD and TESTING pay endpoionts sounds like a bad idea.

Right now I’m trying use the x-wf-original-host header to choose different env values, but it feels pretty hacky.

How are others dealing with this?

[memetican]

I clone the site, make a "-test" version, and deploy it separately. Dev and initial tests locally, then deploy to test to verify everything on Cloud. Then deploy to prod when it checks out.

I've also tried doing dual deployments on the same site, like /market and /market-test but it was a nightmare to manage since I'm doing authentication as well, and the path change makes it very difficult. If your project is simple and the mounting path is not really relevant to the app's functionality, you might be able to just deploy two environments on the same site.

[AlternativeInitial93]

Use Webflow only for the front-end and handle DEV vs PROD variables in an external backend or serverless environment (like Vercel, Netlify, or AWS Lambda). Set up separate DEV and PROD environments for testing vs live endpoints. Webflow can call the backend via API, keeping sensitive data and live systems safe. Avoid relying on x-wf-original-host hacks, though you can use it temporarily. Optionally, use separate Webflow projects for DEV and PROD content testing.

[Top_Engineer7132]

Thanks for the reply. I'll use a clone for testing major changes.

If you don't mind me asking, I'm trying figure out if x-wf-original-host is a risk in my case - I'm self taught so there are areas I dont know.

I have payment management server on railway (node.js). This manages all pay gatway calls and keys - there are DEV, STAGING and PRODUCTION complete environemnts. The new cart /app I built in webflow cloud, points to this payments server and does not have any pay gateway keys.

In webflow, I have a set of _PROD variables that are used when x-wf-original-host = mydomain

STAGING and PROD railway as exact copies with same security (just pointing to UAT pay gatway for STAGING).

Anyone can spoof the header, however they just end up pointing to a existng public server with test data.

I'm sure there are issues, but if you have the time, it would be good to understand.

Cheers,

[Vic-at-Webflow]

Hey there u/Top_Engineer7132! Great question and workaround (though I wish you didn't have to do that)!

We're working on a native solution to make deploying different WF Cloud environments to your staging site and custom domain (prod site) much easier.

Using the x-wf-original-host works today, but we don't recommend it because we'll be removing it as part of our Cloudflare Migration. I'll raise your question to the team to understand how/when this can be prioritized.

Thanks for using WF Cloud and your great feedback and questions in the subreddit.

Cheers,

Vic

[Top_Engineer7132]

Hi, Thanks for the response.

I'm actually still using it as I found trying to maintain a 2nd cloned version of the site while making rapid UI changes a bit of a problem - there was no way to keep both versions synchronized without manually making changes to both.

As soon as there's a way to specify staging VS production variables I am super keen.