Production, staging and development — what each is for, and what you can add.
An environment is one running copy of your application: its own machines, its own database, its own domain, its own variables.
Every project's first environment is production, and its machine name cannot be changed. The name is in DNS, in the certificates already issued, and in every log line already written — renaming it does not rename any of those, it just makes them disagree.
Machines get a .vallic.cloud address built from that name, so you have
somewhere working to point at before your own domain is ready.
Environments cannot be added until the project's initial setup is finished. There is nothing to copy the shape and stack from until then.
| Type | For | Machine | Backups kept | Protected by default |
|---|---|---|---|---|
| Production | The live site | What you configured | A week of dailies, or what you bought | Yes |
| Staging | Checking a release before customers see it | A share of the shared non-production machine — two shares | The last three days | No |
| Development | One feature branch | A share of the same machine — one share | The last day | Never |
A project has one staging environment, and it comes first: a development
environment is a branch on its way towards staging, so one cannot be added
until staging exists. Development environments are named after their branch —
dev- and the branch name.
Everything beyond production shares one machine, chosen when the project is set up and resized afterwards like any other. How many environments you run on it decides how much each one gets: staging takes two shares to a feature branch's one, so three environments give staging half the machine and a quarter to each of the others, and six give staging two sevenths and each of the rest a seventh.
The count itself costs nothing. Raising it gives every environment less; lowering it gives them more. Giving them all more means a bigger machine. Both levers are on the configurator when the project is set up, and both change later under Commercial terms on the project's configuration page. Adding an environment past the count opens that dialog instead of failing, and a running environment cannot be un-bought from there — delete it first.
Everything is backed up, but the environments beyond production keep less history: they are rebuilt from a branch, and keeping weeks of them would spend storage on something nobody will restore. See Backups.
Protection is a default rather than a rule. Production arrives protected because that is the safe answer to have without thinking about it, and it can be turned off deliberately. A development environment is never protected: it lives while its branch does, and on GitHub deleting the branch removes it.
Every environment other than production runs as a single machine, whatever production runs. There is no reason to pay for a high-availability pair to check a release on — and if the thing being checked is the high-availability behaviour itself, that is a production change with a rollback, not a staging question.
Every environment answers on a …vallic.cloud hostname from the moment it
exists, so there is somewhere working to point at before your own domain is
ready. That name is always a direct route to the machine — it is never put
behind a CDN — which is what gives you a way in that does not depend on a cache
when you are trying to work out whether something is broken.
Adding your own is two records, shown on the Routing tab with the values filled in:
Publishing the CNAME proves control on its own, so the TXT record is only needed if you want to be verified before moving traffic — which is what you want when migrating a live site in without a gap. An apex domain cannot hold a CNAME, so there the TXT record is the only proof, and the address is given as A records or as ALIAS/ANAME if your provider has them.
One domain per environment is the canonical one, marked on the Routing tab. Every other hostname it answers on redirects there — so a site with a real domain stops being reachable at two addresses, which is what search engines and absolute links both want.
The platform hostname stays a direct route to the machine and is not itself redirected away until you promote one of your own domains; promoting an unverified domain is refused, because pointing every address at a name nobody has proved control of would take a working site off the air.
Backups → Copy from another environment copies a running environment's
database and files, as they are right now, into another environment of the same
project. It replaces rather than merges, and production can never be the one
copied into. Nothing is scrubbed on the way unless you declare it in
.vallic/commands/sanitization.yml — Backups has the details.
Variables covers configuration that differs between them, Domains covers putting your own name on one, and Deployments covers what happens when code reaches it.