4. Add a database and wire its secret

Overview

The API keeps the waitlist in memory, so every location has its own list and a restart empties it. This part stores the database credentials in a secret, installs a PostgreSQL database from the Template Catalog in its own GVC, and points the API at it, so a stateless tier that spans providers writes to one source of truth. The database and the API read that secret the way every workload on Control Plane reads every secret, through an identity, a policy, and a reference, so the password appears in no manifest or environment variable. What you’ll build:

A dictionary secret, db-credentials, holding the database user, password, and name.
A second GVC, quickstart-db, with a single location.
A PostgreSQL release named db in it: the db-postgres workload, its volume set, and the identity and policy the template creates so the database can read the secret.
An identity for the API, api-identity, and a policy granting it reveal on the same secret.
The api workload writing every location’s signups to the one database.

The workload api connects to db-postgres at db-postgres.quickstart-db.cpln.local:5432 across GVCs over the internal network. The API's identity api-identity and the database's identity db-pg-identity both reveal the secret db-credentials, each granted by its own policy. One secret, two readers, and one database that every location writes to.

Why a second GVC

This template runs one PostgreSQL replica with one volume. In quickstart-gvc it would run once per location, as two separate databases, so it gets a GVC with a single location; a database that spans locations is the Postgres Multi-Location template. The API reaches it across GVCs over the internal network, admitted by the release’s internal firewall.

How secret access works

A workload reads a secret only when three things are all in place:

Step	What must be true	Without it
1. Identity	An identity is attached to the workload (`spec.identityLink`)	The workload has nothing to authenticate as; its secret references cannot resolve and its deployment pauses
2. Policy	A policy grants that identity `reveal` on the secret	The identity is not allowed to read the secret; the deployment stays paused until access is granted
3. Reference	The secret is injected as `cpln://secret/NAME.KEY` (env var or volume)	The workload never receives the value; there is nothing to inject

The permission to grant is reveal. The similarly named view permission exposes only a secret’s metadata, never its value.

Prerequisites

Completed 3. Service-to-service communication, with api storing the frontend’s signups in memory.
For the CLI and AI Agent paths: the CLI installed and logged in, as in part 2.

Console
CLI
Terraform
Pulumi
AI Agent

Step 1: Store the database credentials as a secret

Open the secret form

Click Secrets in the left menu, then click New. Enter db-credentials as the Name and select Dictionary as the Type.

Add the three entries

Click Data in the left pane and add three rows, each a Key and a Value:

Key	Value
`username`	`api`
`password`	a password of your own
`database`	`waitlist`

Click Create. PostgreSQL creates that user and that database on its first boot, and the API signs in with the same values.

Step 2: Create the database GVC

Open the Create GVC form

Click the Create dropdown in the upper right corner and select GVC.

Name it and pick one location

Enter quickstart-db as the name. Click Locations, then Add Location, select aws-us-west-2, and click OK.

Create the GVC

Click Create. When the Console asks Set as Current Context?, click No, Just View, so the sidebar keeps showing quickstart-gvc.

Step 3: Install PostgreSQL from the Template Catalog

Open the template

In the left menu under Templates, click Catalog, then select the postgres template and click Create Template Release.

Configure the release

Select quickstart-db as the GVC, enter db as the Release Name, and make sure 3.4.1 is the selected Template Version. This part is written against 3.4.1; other versions differ.

Point it at the secret and admit the API

In the values editor, under config, set credentialsSecretName to db-credentials. Under internalAccess, set type to workload-list and list //gvc/quickstart-gvc/workload/api under workloads, so the API is admitted from its own GVC.

Install

Click Install App. The Console opens the new release, listing what it created: the db-postgres workload, the db-pg-vs volume set, and the db-pg-identity identity with the db-pg-policy policy that lets the database read your secret.

Step 4: Create an identity for the API

With quickstart-gvc as the current context, click Identities in the left menu, then click New. Enter api-identity as the Name and click Create.

Step 5: Grant access with a policy

Create the policy

Click Policies in the left menu, then click New. Enter api-db-policy as the Name. Click Target in the left pane and select Secret as the Kind.

Target the secret

Click Items in the left pane, add an item, select db-credentials, and confirm.

Bind the reveal permission

Click Bindings in the left pane and add a binding. Under Permissions select reveal; under Identities select api-identity from the quickstart-gvc GVC. Confirm.

Create the policy

Click Create.

Step 6: Attach the identity and reference the secret

Attach the identity

Open the api workload in quickstart-gvc, click Identity in the left pane, and select api-identity under Identity Name.

Add the connection variables

Click Containers in the left pane and open the Env Vars tab. Click Add Environment Variable four times and fill the rows:

Name	Value type	Value
`PGHOST`	`Literal Value`	`db-postgres.quickstart-db.cpln.local`
`PGDATABASE`	`CPLN Secret`	`db-credentials`, with `database` as the `Property`
`PGUSER`	`CPLN Secret`	`db-credentials`, with `username` as the `Property`
`PGPASSWORD`	`CPLN Secret`	`db-credentials`, with `password` as the `Property`

The three secret rows become the references cpln://secret/db-credentials.database, cpln://secret/db-credentials.username, and cpln://secret/db-credentials.password.

Update

Click Update. The workload rolls out a new version whose container receives the credentials from the secret.

Step 1: Store the database credentials as a secret

The password is generated and never printed; PostgreSQL creates that user and that database on its first boot, and the API signs in with the same values:

cpln secret create-dictionary --name db-credentials \
  --entry username=api \
  --entry password="$(openssl rand -hex 16)" \
  --entry database=waitlist

Step 2: Create the database GVC

cpln gvc create --name quickstart-db --location aws-us-west-2

Step 3: Install PostgreSQL from the Template Catalog

Create db-values.yaml. It points the release at the secret and admits api from its own GVC:

config:
  credentialsSecretName: db-credentials
internalAccess:
  type: workload-list
  workloads:
    - //gvc/quickstart-gvc/workload/api

Install the template as a release named db:

cpln helm install db oci://ghcr.io/controlplane-com/templates/postgres \
  --version 3.4.1 \
  --gvc quickstart-db \
  -f db-values.yaml

The output lists what the release created:

Created /org/my-org/gvc/quickstart-db/identity/db-pg-identity
Created /org/my-org/gvc/quickstart-db/volumeset/db-pg-vs
Created /org/my-org/policy/db-pg-policy
Created /org/my-org/gvc/quickstart-db/workload/db-postgres

Release 'db' has been installed successfully!

The db-pg-policy policy lets the database’s own identity read your secret; the API gets the same access in the next steps.

Step 4: Create an identity for the API

cpln identity create --name api-identity --gvc quickstart-gvc

Step 5: Grant access with a policy

Create a policy targeting the secret:

cpln policy create --name api-db-policy \
  --target-kind secret \
  --resource db-credentials

Bind the reveal permission to the identity:

cpln policy add-binding api-db-policy \
  --permission reveal \
  --identity api-identity \
  --gvc quickstart-gvc

Step 6: Attach the identity and reference the secret

cpln workload update api --gvc quickstart-gvc \
  --set spec.identityLink=api-identity \
  --set spec.containers.api.env.PGHOST.value=db-postgres.quickstart-db.cpln.local \
  --set spec.containers.api.env.PGDATABASE.value=cpln://secret/db-credentials.database \
  --set spec.containers.api.env.PGUSER.value=cpln://secret/db-credentials.username \
  --set spec.containers.api.env.PGPASSWORD.value=cpln://secret/db-credentials.password

The workload rolls out a new version whose container receives the credentials from the secret.

Step 1: Define the secret, the database GVC, and the release

Add to your main.tf. The password arrives through a sensitive variable, so it lands in no configuration file; the release depends on the secret because PostgreSQL reads it on its first boot:

variable "db_password" {
  type      = string
  sensitive = true
}

resource "cpln_secret" "db_credentials" {
  name = "db-credentials"

  dictionary = {
    username = "api"
    password = var.db_password
    database = "waitlist"
  }
}

resource "cpln_gvc" "db" {
  name        = "quickstart-db"
  description = "The database GVC"

  locations = ["aws-us-west-2"]
}

resource "cpln_catalog_template" "db" {
  depends_on = [cpln_secret.db_credentials]

  name     = "db"
  template = "postgres"
  version  = "3.4.1"
  gvc      = cpln_gvc.db.name

  values = <<-EOT
    config:
      credentialsSecretName: db-credentials
    internalAccess:
      type: workload-list
      workloads:
        - //gvc/quickstart-gvc/workload/api
  EOT
}

The release creates the db-postgres workload, its volume set, and the identity and policy that let the database read the secret; every other value keeps the template’s default.

Step 2: Define the identity and the policy

resource "cpln_identity" "api" {
  gvc  = cpln_gvc.quickstart.name
  name = "api-identity"
}

resource "cpln_policy" "api_db" {
  name         = "api-db-policy"
  target_kind  = "secret"
  target_links = [cpln_secret.db_credentials.name]

  binding {
    permissions     = ["reveal"]
    principal_links = [cpln_identity.api.self_link]
  }
}

Step 3: Attach the identity and reference the secret

In cpln_workload.api, attach the identity, add the connection variables to the container, and make the workload depend on the policy so the references resolve on its first rollout:

resource "cpln_workload" "api" {
  depends_on = [cpln_policy.api_db]

  identity_link = cpln_identity.api.self_link

  # ...

    env = {
      PGHOST     = "db-postgres.quickstart-db.cpln.local"
      PGDATABASE = "cpln://secret/db-credentials.database"
      PGUSER     = "cpln://secret/db-credentials.username"
      PGPASSWORD = "cpln://secret/db-credentials.password"
    }

Step 4: Apply

var.db_password has no default, so write it once to a file Terraform reads on every run:

printf 'db_password = "%s"\n' "$(openssl rand -hex 16)" > terraform.tfvars

Then apply:

terraform apply

Keep terraform.tfvars out of version control, and leave the password alone once the database has booted. PostgreSQL creates the user on its first boot and keeps it on its volume, so changing the secret afterwards leaves the API unable to sign in the next time its replicas restart, including the forced redeployment in part 5. Without the file, Terraform prompts for the password on every later apply and on terraform destroy, and a different answer rotates it.

The Terraform Registry documentation lists every catalog template option.

Step 1: Store the database password

pulumi config set --secret dbPassword $(openssl rand -hex 16)

Step 2: Define the secret, the database GVC, and the release

The release depends on the secret because PostgreSQL reads it on its first boot; every value other than the secret name and the access keeps the template’s default.

Add these resources, and the identity and policy in step 3, above the api workload you wrote in part 3, not below it. Step 4 makes api reference the identity and the policy, and every language on this page resolves names in the order they appear: a reference that sits above its declaration fails to compile in TypeScript, Go, and C#, and raises NameError in Python.

TypeScript
Python
Go
C#

Add to your index.ts:

import * as pulumi from "@pulumi/pulumi";

const config = new pulumi.Config();
const dbPassword = config.requireSecret("dbPassword");

// The database credentials, read by PostgreSQL and by the API
const dbCredentials = new cpln.Secret("db-credentials", {
  name: "db-credentials",
  dictionary: {
    username: "api",
    password: dbPassword,
    database: "waitlist",
  },
});

// The database GVC: one location, because PostgreSQL keeps its data on a disk
const dbGvc = new cpln.Gvc("quickstart-db", {
  name: "quickstart-db",
  description: "The database GVC",
  locations: ["aws-us-west-2"],
});

// PostgreSQL from the Template Catalog
const db = new cpln.CatalogTemplate("db", {
  name: "db",
  template: "postgres",
  version: "3.4.1",
  gvc: dbGvc.name,
  values: `config:
  credentialsSecretName: db-credentials
internalAccess:
  type: workload-list
  workloads:
    - //gvc/quickstart-gvc/workload/api
`,
}, { dependsOn: [dbCredentials] });

Add to your __main__.py:

config = pulumi.Config()
db_password = config.require_secret("dbPassword")

# The database credentials, read by PostgreSQL and by the API
db_credentials = cpln.Secret("db-credentials",
    name="db-credentials",
    dictionary={
        "username": "api",
        "password": db_password,
        "database": "waitlist",
    })

# The database GVC: one location, because PostgreSQL keeps its data on a disk
db_gvc = cpln.Gvc("quickstart-db",
    name="quickstart-db",
    description="The database GVC",
    locations=["aws-us-west-2"])

# PostgreSQL from the Template Catalog
db = cpln.CatalogTemplate("db",
    name="db",
    template="postgres",
    version="3.4.1",
    gvc=db_gvc.name,
    values="""config:
  credentialsSecretName: db-credentials
internalAccess:
  type: workload-list
  workloads:
    - //gvc/quickstart-gvc/workload/api
""",
    opts=pulumi.ResourceOptions(depends_on=[db_credentials]))

Add github.com/pulumi/pulumi/sdk/v3/go/pulumi/config to your imports and run go mod tidy, which records the dependency that package pulls in. Then add inside pulumi.Run in your main.go:

conf := config.New(ctx, "")
dbPassword := conf.RequireSecret("dbPassword")

// The database credentials, read by PostgreSQL and by the API
dbCredentials, err := cpln.NewSecret(ctx, "db-credentials", &cpln.SecretArgs{
	Name: pulumi.String("db-credentials"),
	Dictionary: pulumi.StringMap{
		"username": pulumi.String("api"),
		"password": dbPassword,
		"database": pulumi.String("waitlist"),
	},
})
if err != nil {
	return err
}

// The database GVC: one location, because PostgreSQL keeps its data on a disk
dbGvc, err := cpln.NewGvc(ctx, "quickstart-db", &cpln.GvcArgs{
	Name:        pulumi.String("quickstart-db"),
	Description: pulumi.String("The database GVC"),
	Locations:   pulumi.StringArray{pulumi.String("aws-us-west-2")},
})
if err != nil {
	return err
}

// PostgreSQL from the Template Catalog
db, err := cpln.NewCatalogTemplate(ctx, "db", &cpln.CatalogTemplateArgs{
	Name:     pulumi.String("db"),
	Template: pulumi.String("postgres"),
	Version:  pulumi.String("3.4.1"),
	Gvc:      dbGvc.Name,
	Values: pulumi.String(`config:
  credentialsSecretName: db-credentials
internalAccess:
  type: workload-list
  workloads:
    - //gvc/quickstart-gvc/workload/api
`),
}, pulumi.DependsOn([]pulumi.Resource{dbCredentials}))
if err != nil {
	return err
}
_ = db

Add to your Program.cs:

var config = new Pulumi.Config();
var dbPassword = config.RequireSecret("dbPassword");

// The database credentials, read by PostgreSQL and by the API
var dbCredentials = new Secret("db-credentials", new SecretArgs
{
    Name = "db-credentials",
    Dictionary =
    {
        { "username", "api" },
        { "password", dbPassword },
        { "database", "waitlist" }
    }
});

// The database GVC: one location, because PostgreSQL keeps its data on a disk
var dbGvc = new Gvc("quickstart-db", new GvcArgs
{
    Name = "quickstart-db",
    Description = "The database GVC",
    Locations = new[] { "aws-us-west-2" }
});

// PostgreSQL from the Template Catalog
var db = new CatalogTemplate("db", new CatalogTemplateArgs
{
    Name = "db",
    Template = "postgres",
    Version = "3.4.1",
    Gvc = dbGvc.Name,
    Values = @"config:
  credentialsSecretName: db-credentials
internalAccess:
  type: workload-list
  workloads:
    - //gvc/quickstart-gvc/workload/api
"
}, new CustomResourceOptions { DependsOn = { dbCredentials } });

The release creates the db-postgres workload, its volume set, and the identity and policy that let the database read the secret.

Step 3: Define the identity and the policy

TypeScript
Python
Go
C#

// Identity for the API
const apiIdentity = new cpln.Identity("api-identity", {
  gvc: gvc.name,
  name: "api-identity",
});

// Policy granting the identity reveal on the database credentials
const apiDbPolicy = new cpln.Policy("api-db-policy", {
  name: "api-db-policy",
  targetKind: "secret",
  targetLinks: [dbCredentials.name],
  bindings: [
    {
      permissions: ["reveal"],
      principalLinks: [apiIdentity.selfLink],
    },
  ],
});

# Identity for the API
api_identity = cpln.Identity("api-identity",
    gvc=gvc.name,
    name="api-identity")

# Policy granting the identity reveal on the database credentials
api_db_policy = cpln.Policy("api-db-policy",
    name="api-db-policy",
    target_kind="secret",
    target_links=[db_credentials.name],
    bindings=[cpln.PolicyBindingArgs(
        permissions=["reveal"],
        principal_links=[api_identity.self_link],
    )])

// Identity for the API
apiIdentity, err := cpln.NewIdentity(ctx, "api-identity", &cpln.IdentityArgs{
	Gvc:  gvc.Name,
	Name: pulumi.String("api-identity"),
})
if err != nil {
	return err
}

// Policy granting the identity reveal on the database credentials
apiDbPolicy, err := cpln.NewPolicy(ctx, "api-db-policy", &cpln.PolicyArgs{
	Name:        pulumi.String("api-db-policy"),
	TargetKind:  pulumi.String("secret"),
	TargetLinks: pulumi.StringArray{dbCredentials.Name},
	Bindings: cpln.PolicyBindingArray{
		&cpln.PolicyBindingArgs{
			Permissions:    pulumi.StringArray{pulumi.String("reveal")},
			PrincipalLinks: pulumi.StringArray{apiIdentity.SelfLink},
		},
	},
})
if err != nil {
	return err
}

// Identity for the API
var apiIdentity = new Identity("api-identity", new IdentityArgs
{
    Gvc = gvc.Name,
    Name = "api-identity"
});

// Policy granting the identity reveal on the database credentials
var apiDbPolicy = new Policy("api-db-policy", new PolicyArgs
{
    Name = "api-db-policy",
    TargetKind = "secret",
    TargetLinks = { dbCredentials.Name },
    Bindings = new[]
    {
        new PolicyBindingArgs
        {
            Permissions = new[] { "reveal" },
            PrincipalLinks = { apiIdentity.SelfLink }
        }
    }
});

Step 4: Attach the identity and reference the secret

In the api workload, attach the identity, add the connection variables to the container, and make the workload depend on the policy so the references resolve on its first rollout:

TypeScript
Python
Go
C#

  identityLink: apiIdentity.selfLink,
  // ...
      env: {
        PGHOST: "db-postgres.quickstart-db.cpln.local",
        PGDATABASE: "cpln://secret/db-credentials.database",
        PGUSER: "cpln://secret/db-credentials.username",
        PGPASSWORD: "cpln://secret/db-credentials.password",
      },
  // ...
}, { dependsOn: [apiDbPolicy] });

    identity_link=api_identity.self_link,
    # ...
        env={
            "PGHOST": "db-postgres.quickstart-db.cpln.local",
            "PGDATABASE": "cpln://secret/db-credentials.database",
            "PGUSER": "cpln://secret/db-credentials.username",
            "PGPASSWORD": "cpln://secret/db-credentials.password",
        },
    # ...
    opts=pulumi.ResourceOptions(depends_on=[api_db_policy]))

	IdentityLink: apiIdentity.SelfLink,
	// ...
			Env: pulumi.StringMap{
				"PGHOST":     pulumi.String("db-postgres.quickstart-db.cpln.local"),
				"PGDATABASE": pulumi.String("cpln://secret/db-credentials.database"),
				"PGUSER":     pulumi.String("cpln://secret/db-credentials.username"),
				"PGPASSWORD": pulumi.String("cpln://secret/db-credentials.password"),
			},
	// ...
}, pulumi.DependsOn([]pulumi.Resource{apiDbPolicy}))

    IdentityLink = apiIdentity.SelfLink,
    // ...
            Env =
            {
                { "PGHOST", "db-postgres.quickstart-db.cpln.local" },
                { "PGDATABASE", "cpln://secret/db-credentials.database" },
                { "PGUSER", "cpln://secret/db-credentials.username" },
                { "PGPASSWORD", "cpln://secret/db-credentials.password" }
            }
    // ...
}, new CustomResourceOptions { DependsOn = { apiDbPolicy } });

Step 5: Deploy

pulumi up

The Pulumi Registry documentation lists every catalog template option.

Step 1: Store the database credentials as a secret

The agent never handles secret values, so create the secret yourself. With the CLI, the password is generated and never printed:

cpln secret create-dictionary --name db-credentials \
  --entry username=api \
  --entry password="$(openssl rand -hex 16)" \
  --entry database=waitlist

PostgreSQL creates that user and that database on its first boot, and the API signs in with the same values.

Step 2: Create the database GVC

The first prompt names your org, so it works in a new conversation too. Replace my-org with your org name:

Using org "my-org", create a GVC called "quickstart-db" with the
single location aws-us-west-2.

The agent creates the GVC with its one location.

Step 3: Install PostgreSQL from the Template Catalog

Install the postgres template, version 3.4.1, in that GVC as a
release called "db". Use the secret "db-credentials" for its
credentials, and let only the api workload in "quickstart-gvc"
reach it.

The agent reads the template’s example values, sets the secret name and the workload list in them, and installs the release. The release creates the db-postgres workload, the db-pg-vs volume set, and the db-pg-identity identity with the db-pg-policy policy that lets the database read your secret.

Step 4: Grant the API access to the secret

Give the api workload access to the secret "db-credentials",
through an identity called "api-identity" and a policy called
"api-db-policy".

The agent creates the identity in quickstart-gvc, attaches it to api, and creates the policy granting the identity reveal on the secret, in one call. The secret’s value never reaches the agent.

Step 5: Reference the secret

Set these environment variables on the api workload: PGHOST to
db-postgres.quickstart-db.cpln.local, and PGDATABASE, PGUSER,
and PGPASSWORD to the database, username, and password entries
of the secret "db-credentials".

The agent adds the four variables, the last three as cpln://secret/db-credentials.database, .username, and .password references, and follows the rollout. The new version’s container receives the credentials from the secret.

Verify

Once db-postgres and the new api version report Ready, reload the frontend. The badge next to the Recent signups heading now says Stored in PostgreSQL with the location nearest to you, and the list is empty because the part 3 signups lived in memory. Join the waitlist, then open another location’s endpoint from the Deployments page (or ask your AI agent for it). It shows the same list, because every API replica now writes to the one database in quickstart-db. The list also survives a restart. Force a redeployment of api (Actions, then Force Redeployment in the Console, or cpln workload force-redeployment api --gvc quickstart-gvc), reload once it reports Ready (a 503 from the API means the mesh is still switching, so reload once more), and the signups are still there.

The API authenticated to a database it reaches across GVCs, with credentials it reads through the identity, policy, and secret reference chain, and the password appears in no manifest, configuration, or image.

A workload that references a secret its identity is not allowed to reveal does not roll out. The deployment reports

The identity api-identity is not allowed to reveal the secret db-credentials. Workload updates are paused until the identity is granted access or the reference to the secret is removed.

, while the version already serving keeps answering. Grant the access, then resume with cpln workload force-redeployment api --gvc quickstart-gvc or, in the Console, Actions then Force Redeployment.

What you’ve learned

One secret, two readers: the database and the API read the same dictionary secret, each through its own identity and policy, and the value sits in neither workload’s configuration.
A template is a whole service: one catalog release brings the workload, its volume set, and the identity and policy it needs, managed together as the release.
Unreplicated state stays in one location: this template runs one PostgreSQL replica with one volume, so it lives in a single-location GVC. A production database uses a replicated template such as Postgres Multi-Location, which spans locations with a primary, streaming replicas, and automatic failover.
The access chain: an identity attached to the workload, a policy granting it reveal on the secret, and a cpln://secret/ reference where the value is needed. Miss one and the value is absent.
reveal, not view: view exposes a secret’s metadata, only reveal exposes its value.
Safe by default: a workload whose reference cannot resolve keeps serving its previous version instead of rolling out without the value.

Next steps

5. Observe your workload

Follow one request through the logs of both workloads, read the metrics every workload publishes, and open a trace that spans the frontend and the API.

Clean up

To remove everything the series has created so far:

Console
CLI
Terraform
Pulumi
AI Agent

Delete the policy

Open Policies, select api-db-policy, click Actions, then Delete, and confirm.

Uninstall the database release

Under Templates, click Releases, open db, click Actions, then Uninstall, and confirm.

Delete the database GVC

Open quickstart-db, click Actions, then Delete, type the GVC name to confirm, and click Delete.

Delete the application GVC

Open quickstart-gvc, click Actions, then Delete, type the GVC name to confirm, and click Delete. web, frontend, api, and api-identity go with it.

Delete the secret

Open Secrets, select db-credentials, click Actions, then Delete, and confirm.

Delete the images

Open Images, select frontend, and click Actions, then Delete to remove all its tags. Repeat for api.

cpln policy delete api-db-policy
cpln helm uninstall db
cpln gvc delete quickstart-db
cpln gvc delete quickstart-gvc
cpln secret delete db-credentials
cpln image delete frontend:1.0
cpln image delete frontend:1.1
cpln image delete api:1.0

terraform destroy

The images were built by the CLI, so delete them with it: cpln image delete frontend:1.0, cpln image delete frontend:1.1, and cpln image delete api:1.0.

pulumi destroy

The images were built by the CLI, so delete them with it: cpln image delete frontend:1.0, cpln image delete frontend:1.1, and cpln image delete api:1.0.

Delete the policy "api-db-policy", uninstall the release "db",
then delete the GVCs "quickstart-db" and "quickstart-gvc" and
the images frontend:1.0, frontend:1.1, and api:1.0.

The agent lists what goes, including the release’s volume set and the data on it, and asks you to confirm. The agent cannot delete a secret, so remove that yourself:

cpln secret delete db-credentials

Uninstalling the release removes its volume set and the data on it. A --remote build also pushes the build cache images frontend-cache:latest and api-cache:latest; delete those too if you built without Docker.

Getting Started

Quickstart

Concepts

Core

Reference

4. Add a database and wire its secret

Overview

Prerequisites

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Create an identity for the API

Step 5: Grant access with a policy

Step 6: Attach the identity and reference the secret

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Create an identity for the API

Step 5: Grant access with a policy

Step 6: Attach the identity and reference the secret

Step 1: Define the secret, the database GVC, and the release

Step 2: Define the identity and the policy

Step 3: Attach the identity and reference the secret

Step 4: Apply

Step 1: Store the database password

Step 2: Define the secret, the database GVC, and the release

Step 3: Define the identity and the policy

Step 4: Attach the identity and reference the secret

Step 5: Deploy

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Grant the API access to the secret

Step 5: Reference the secret

Verify

What you’ve learned

Next steps

5. Observe your workload

Clean up

​Overview

​Prerequisites

​Step 1: Store the database credentials as a secret

​Step 2: Create the database GVC

​Step 3: Install PostgreSQL from the Template Catalog

​Step 4: Create an identity for the API

​Step 5: Grant access with a policy

​Step 6: Attach the identity and reference the secret

​Step 1: Store the database credentials as a secret

​Step 2: Create the database GVC

​Step 3: Install PostgreSQL from the Template Catalog

​Step 4: Create an identity for the API

​Step 5: Grant access with a policy

​Step 6: Attach the identity and reference the secret

​Step 1: Define the secret, the database GVC, and the release

​Step 2: Define the identity and the policy

​Step 3: Attach the identity and reference the secret

​Step 4: Apply

​Step 1: Store the database password

​Step 2: Define the secret, the database GVC, and the release

​Step 3: Define the identity and the policy

​Step 4: Attach the identity and reference the secret

​Step 5: Deploy

​Step 1: Store the database credentials as a secret

​Step 2: Create the database GVC

​Step 3: Install PostgreSQL from the Template Catalog

​Step 4: Grant the API access to the secret

​Step 5: Reference the secret

​Verify

​What you’ve learned

​Next steps

5. Observe your workload

​Clean up

Overview

Prerequisites

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Create an identity for the API

Step 5: Grant access with a policy

Step 6: Attach the identity and reference the secret

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Create an identity for the API

Step 5: Grant access with a policy

Step 6: Attach the identity and reference the secret

Step 1: Define the secret, the database GVC, and the release

Step 2: Define the identity and the policy

Step 3: Attach the identity and reference the secret

Step 4: Apply

Step 1: Store the database password

Step 2: Define the secret, the database GVC, and the release

Step 3: Define the identity and the policy

Step 4: Attach the identity and reference the secret

Step 5: Deploy

Step 1: Store the database credentials as a secret

Step 2: Create the database GVC

Step 3: Install PostgreSQL from the Template Catalog

Step 4: Grant the API access to the secret

Step 5: Reference the secret

Verify

What you’ve learned

Next steps

Clean up