Staging to production
A project has exactly one Content Deploy configuration and one CDN endpoint, so separating environments means separating projects: one for staging, one for production. Content moves between them when you promote it.
VITE_COMVI_CDN_URL=https://cdn.comvi.io/<staging-token>VITE_COMVI_CDN_URL=https://cdn.comvi.io/<production-token>cdnLoader({ cdnUrl: import.meta.env.VITE_COMVI_CDN_URL })The variable name is yours; the loader reads only cdnUrl.
Set up
Section titled “Set up”-
Create two projects, for example
checkoutandcheckout-staging, with the same source language. It cannot be changed after creation. -
Enable Content Deploy in each under Settings → Content Deploy: pick the locales and namespaces and save. Each project gets its own endpoint URL at the top of the page.
-
Point each app at its own endpoint through the
VITE_COMVI_CDN_URLvariable. -
Do all the work in staging. Translators write there, reviewers approve there, QA looks at the staging app. Staging deploys within a minute of each save.
-
Promote on your release cadence with export and import, or with the CLI.
Projects and members are both capped per plan, so two projects may be the whole allowance. Check the current limits first.
Promote with export and import
Section titled “Promote with export and import”-
In staging, open Export, select the locales and namespaces, and set the status filter to
Translated. -
Download the archive, laid out as
<namespace>/<locale>.json. -
In production, open Import and upload the archive.
-
Resolve conflicts with Keep existing or Use imported, or apply one policy to everything left unresolved.
-
Commit the import. Production’s Content Deploy picks the change up on its own debounce.
This path has a status filter, so use it whenever staging still holds work in progress. See Import & export.
Promote with the CLI
Section titled “Promote with the CLI”COMVI_API_KEY=$STAGING_KEY npx --package @comvi/cli comvi pull --path ./promoteCOMVI_API_KEY=$PROD_KEY npx --package @comvi/cli comvi push --path ./promote --force-mode keepThe pull takes every value the staging key can see, whatever its status, and the push writes
all of them into production as Translated. Use it only when staging is fully reviewed at
release time. --force-mode keep leaves existing production values alone on conflict;
override replaces them. CI/CD integration
wires it to a release tag.
Trade-offs
Section titled “Trade-offs”A draft in staging cannot reach production, because nothing crosses between two projects on its own. The cost is two projects to keep in step: languages and namespaces added twice, members with access to both, and two slots of the plan’s project limit. Translation memory and glossaries are organization-level, so they stay shared.
Use a second organization instead when the environments need different people, not only different content: an agency that works staging but must never see production, or separate billing. Translation memory and glossaries then no longer carry over.
Test a new string
Section titled “Test a new string”- A developer adds a key in the staging dashboard or pushes a translation file there.
- Translators fill it in. Every saved value lands as
Needs Review. - Staging deploys within about a minute, and QA checks the string in the staging app.
- A reviewer sets the value to
Translated. - The next promotion carries it to production.
A key that shows in production but not in staging usually means the staging project’s Content Deploy locale or namespace selection leaves it out.
Rollback
Section titled “Rollback”There is no rollback. A failed deploy leaves the files it uploaded live next to the ones it
never replaced, and a successful deploy with bad content has replaced the good content.
Recover with a fresh deploy: fix the values in production and wait for auto-deploy or press
Deploy Now, or re-import the last known-good export. Exports are your rollback points,
so keep a scheduled comvi pull or a regular export archive somewhere durable.