Projects and environments

Gigadrive Network arranges your work in five nested things: an organization owns applications, an application has environments, an environment collects branches, and a branch produces deployments. Knowing which layer a setting lives on saves you looking for it in the wrong place.

Organizations

The organization is the billing and access boundary. It holds the plan, the payment method, the members and every quota that is counted across projects, including how many applications you may create and how many deployments you may run in a day. Product access is granted per organization, so an organization is also the level at which Gigadrive Network is switched on. See Organizations.

Applications

An application is one codebase. It carries the repository link, the root directory to build from when your code lives in a subdirectory, and application-wide switches such as always-warm residency.

Creating one creates two environments with it: Production, which tracks the main and master branches, and Preview, which has no patterns of its own and catches everything else.

Environments

An environment is a running copy of the application with its own configuration. Production and preview cover most projects; you can add more, up to your plan's limit, when you want a staging target with its own variables and its own data.

Environments are where the things that differ between copies live. Storage buckets belong to one environment, so a bucket declared in your config is provisioned separately in production and in preview, each with its own objects. Environment variables can be scoped to an environment too, on top of the organization-wide and application-wide values. See Environments and Environment variables.

Branches

A branch belongs to the environment whose patterns match its name. The production and custom environments are checked first, in creation order, and preview catches anything none of them claim.

Patterns are exact names, or a * wildcard anchored at both ends: main matches only main, while release/* matches every branch under release/. Editing an environment's patterns re-evaluates the branches you already have, so moving staging from preview to a staging environment is a settings change rather than a migration. Branches has the details.

Deployments

A deployment is one immutable build. It belongs to exactly one environment, and to a branch when it came from Git. Nothing about a deployment changes once it is built. What changes is which deployment a hostname points at.

Three kinds of hostname make that concrete:

The first two are aliases and get re-pointed as new deployments go live. The third never moves, which is what makes it safe to link a reviewer to a specific build.

What lives where

Environment variables are the exception worth remembering: they resolve from all three scopes at once, with the narrowest winning. Variable scopes covers the precedence rules.