The Basics

The Server

On snapcd.io we provide a centralised service responsible for configuration, orchestration, output storage and log storage.

The Runner

Runners are self-hosted execution agents, that you deploy in a manner and place of your choosing. Runners use bearer tokens to establish a long-lived, authenticated Websocket connection with snapcd.io. Runners pick up jobs and report back via this connection. A Runner is associated with a Service Principal on your Organization.

Terraform Provider

We are an IaC-first enterprise, so almost everything you can do on snapcd.io can be managed via our Terraform Provider. The snapcd.io API can be interacted with by Users or Service Principals. Users can generate access tokens via the snapcd.io Portal. Service Principals make use of “Client Id”/“Client Secret” pairs in order to obtain an access token. The Terraform Provider authenticates against the API via the same mechanisms.

Modules

On Snap CD a single unit of infrastructure is referred to as a Module. A Module points to Terraform/OpenTofu code (e.g Git reference); can have Inputs from various sources; has its own state file; and is deployed by a Runner. Its Outputs are securely stored on snapcd.io, which can in turn by used as Inputs for other Modules, thereby creating a dependency graph.

Namespaces

Modules are organized into Namespaces.

Stacks

Namespaces are organized into Stacks. A Stack represents a hard delineation. Modules in different Stacks do not influence one another.

We recommend having only a handful of Stacks (e.g. “dev”, “test” and “prod”) and using Namespaces to delineate functional component groupings (e.g. “Networking”, “Storage”, “Customer Portal” or whatever the case may be).