strackt docs
Browse docs

Explanation

Environments

Run production, staging, and preview copies of your application side by side.

Environments

An application in strackt is your codebase. An environment is one running copy of it β€” a specific branch, deployed to a specific server, with its own settings. Most projects end up with more than one: production for real traffic, staging to try changes first, maybe a preview for a feature branch.

Production comes first

Every application starts with a production environment. It's always there and can't be deleted β€” it's the home for your live application.

Adding more environments

You add a staging, preview, or custom environment by cloning one you already have. Cloning copies the source environment's branch, server, settings, and environment variables as a starting point, so a new environment isn't an empty form β€” it's a working copy you adjust. You then point it at a different branch or server if you want it to differ.

Creating one, step by step

Open the environment switcher at the top of any application page and choose New environment…. A short form opens with everything pre-filled from a source environment:

  • Source β€” the environment to clone. It defaults to production; pick another if you'd rather start from staging.
  • Name β€” what you'll call it (up to 64 characters, unique within the application). The reserved names production, staging, and preview are kept for those environment types.
  • Type β€” production, staging, preview, or custom. Production isn't offered once the application already has one.
  • Branch and Server β€” pre-filled from the source. Change either to make the new environment differ.

Submit, and strackt clones the source into a ready-to-deploy environment and drops you on its summary. If the source can't be cloned right now β€” it's mid-deploy, the application is paused, or it has changes waiting to apply β€” you'll see a short note explaining what to do instead of a failure.

What each environment owns

Each environment is independent:

  • Its own branch β€” production might track main while staging tracks develop.
  • Its own server β€” environments can run on the same server or different ones.
  • Its own domains β€” each gets a free strackt address, and you can add your own.
  • Its own environment variables and connected services β€” staging can point at a separate database from production, so a test never touches live data.

Because they're separate, a change you deploy to staging has no effect on production until you deploy it there too.

Switching between them

The bar at the top of the application shows which environment you're looking at. Switch between an application's environments from there, with production listed first. A single-environment application just shows production with nothing extra to choose.

Deploying to the right environment

If you've turned on automatic deploys, a push to your repository deploys to every environment whose branch matches what you pushed. A push to develop deploys your staging environment; a push to main deploys production. Each environment only acts on pushes to its own branch.

Connection details and secrets are set per environment β€” see Manage environment variables β€” so each copy reads its own configuration when it deploys.

Was this helpful?

Related docs