Skip to main content

Environments

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.

#The first one is production

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.

#The other types

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.

#Shape

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.

#What lives on an environment

  • Its source: the branch it tracks — no two environments in a project track the same one — and whether a push to that branch deploys it
  • Variables, and the ones it inherits from the project — see Variables
  • Domains and their certificates
  • Service versions: the database, cache and runtime versions from the catalogue
  • Disks, and which service each one holds — see Storage

#Domains

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:

  • A CNAME at the environment's own hostname (or at the CDN, if the project has one — the tab shows whichever applies).
  • A TXT record proving you control the domain.

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.

#Canonical

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.

#Copying data between them

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.

Next

Variables covers configuration that differs between them, Domains covers putting your own name on one, and Deployments covers what happens when code reaches it.