Providers & Targets

A provider is the SDK package that knows how to provision, destroy, and migrate primitives on one specific cloud or runtime. A target is a runtime instance of a provider.

Providers

Each provider lives in its own npm package and implements one interface:

interface Provider {
  name: string;
  displayName: string;
  provision(primitive, ctx): Promise<ProvisionResult>;
  destroy(primitive, ctx): Promise<void>;
  deploy?(primitive, ctx): Promise<void>;
  migrateData?(primitive, ctx): Promise<MigrateResult>;
}

Currently shipped:

Package	name	What it provisions
@sprintsail/provider-aws	aws	AWS resources in your account
@sprintsail/provider-sprintsail-runtime	sprintsail-runtime	Kubernetes resources on a Sprintsail Runtime cluster

Planned:

• @sprintsail/provider-azure
• @sprintsail/provider-gcp

Targets

A target is a provider:locator string passed to sail deploy, sail destroy, or sail migrate:

aws:us-east-1
sprintsail-runtime:my-prod-cluster

• The provider segment picks the package above.
• The locator is whatever that provider uses to address an instance — for AWS that's a region, for the runtime that's a kubeconfig context name.

You can set a default in sail.config.ts:

export default defineConfig({
  project: 'orders',
  defaultTarget: 'aws:us-east-1',
});

And override per command:

npx sail deploy --target sprintsail-runtime:my-cluster

One project, many targets

Each (project, target) pair has its own state file. That means the same project can be deployed concurrently to multiple targets:

# Production on AWS
npx sail deploy --target aws:us-east-1 --yes

# Staging on the runtime
npx sail deploy --target sprintsail-runtime:staging --yes

The state files live side-by-side (.sail/state.aws.us-east-1.json, .sail/state.sprintsail-runtime.staging.json) and don't interfere.

How sail migrate uses two targets

sail migrate --from <a> --to <b> reads the source state from target <a>, asks target <b>'s provider to provision equivalents, then asks <b>'s provider to copy stateful data using whatever cross-provider mechanism makes sense (Secrets Manager fetch → SealedSecret patch, RDS pg_dump → CNPG, S3 listing → MinIO copy).

The contract: when targets differ, only the destination provider's migrateData runs. It's responsible for pulling from the source. See The sail migrate model.

See capabilities per target

Each provider declares which primitives it supports and at what maturity:

npx sail target capabilities aws
npx sail target capabilities sprintsail-runtime

The output drives the Capability Matrix.