Environments

An environment is a deploy target inside one application. It owns a set of branches, its own environment variables, and its own storage buckets, so a staging deployment can talk to staging data without a second application.

The two you start with

Creating an application creates both of these, and neither can be removed or duplicated:

Production is the only environment whose deployments move the <name>.gigadrive.app URL. A deployment that carries no branch at all, which is what an upload or gigadrive deploy produces, falls back to Preview.

Adding one

1. Open the environments settings

   Go to your application, then Settings, Environments.

2. Create the environment

   Create environment asks for a name and a slug. The slug is filled in from the name and may contain lowercase letters, numbers, and hyphens. It has to be unique within the application, and it is what gigadrive env pull --environment and the API's pull endpoint accept.

3. Route branches to it

   A new environment claims nothing until you give it patterns. Edit branch routing takes exact names like staging and wildcards like release/*. Saving re-evaluates the branches the application already knows about.

4. Give it its variables

   Under Settings, Variables, add a variable and pick the new environment in the scope selector. Values scoped to an environment override application-wide values, which override organization values.

How many environments an application may have depends on the plan, and the two built-in ones count:

What belongs to an environment

• Branches. Each branch is assigned to exactly one environment, and the assignment decides where its pushes deploy.
• Deployments. A deployment always names the environment it ran in, which is also the environment whose variables it was built with.
• Environment variables. A variable can be scoped to one environment, to the whole application, or to the organization. Variable scopes covers the merge order.
• Storage buckets. Bucket names are unique per environment, so uploads in Preview and uploads in Production are two different buckets holding different objects.
• The production URL, which only the Production environment can move.

Sensitive variables are the one thing a custom environment cannot have: the platform accepts them only on Production and Preview.

The environment overview

Each environment has a page in the console showing what it is currently serving. The active deployment sits at the top, with a screenshot of the live site, its URL, and its commit. Under that is an activity card covering the last 24 hours, 7 days, or 30 days: CDN requests, Function invocations, error rate, and bandwidth. Then the environment's recent deployments, its branches, and its buckets.

The active deployment is the newest deployment of that environment that reached the ACTIVE status. A failed build never becomes the active deployment, so a broken push leaves the environment serving what it served before, and the failed attempt shows up under the recent deployments instead.

Environments cannot be deleted from the console or the API today. Taking away a custom environment's branch patterns retires it in practice: nothing matches it any more, and its branches fall back to Preview on their next push.