Templates

Templates

Preconfigured service stacks for databases, caches, observability, CI workers, CMS apps, and other production building blocks

Templates are preconfigured service stacks that deploy databases, applications, and supporting infrastructure in one command. Each template handles container images, ports, volumes, generated credentials, variables, service dependencies, and structured outputs.

Templates create normal Ink services. You can inspect them with service_get, view logs and metrics, attach domains, scale resources, and manage their volumes just like services deployed from a repository or Docker image.

Database templates are self-hosted database services running on Ink with persistent volumes and generated credentials. They are not a separate managed-database product with automatic backups, failover, or managed upgrades unless those features are explicitly added to a template.

Bring any database

Ink can run any database that ships as a container image and can store its data on a mounted volume. The seeded templates below are the turnkey path for common engines, but they are not the limit of what Ink can provision.

For another database, deploy it as a normal service with:

  • source: "image" and the database image, such as an official or private registry image
  • an internal TCP port in ports
  • volume_name, volume_mount_path, and volume_size_gi for durable data
  • env_vars for credentials and database configuration

That service gets the same logs, metrics, scaling controls, DNS options, and volume lifecycle as any other Ink service. User-created and community templates are coming up; until then, use service_create directly for custom database engines.

Seed database templates

Ink ships with database templates provisioned with persistent storage, generated credentials, and sensible defaults.

SlugImagePortVolumeKey env vars
postgrespostgres:175432/var/lib/postgresql/dataPOSTGRES_USER, POSTGRES_PASSWORD (generated), POSTGRES_DB, connection_string
postgres-pgvectorpgvector/pgvector:pg175432/var/lib/postgresql/dataPostgreSQL credentials plus the vector extension
redisredis:76379/dataREDIS_PASSWORD (generated), connection_string
mysqlmysql:83306/var/lib/mysqlMYSQL_ROOT_PASSWORD (generated), MYSQL_DATABASE, connection_string
mongodbmongo:727017/data/dbMONGO_INITDB_ROOT_USERNAME, MONGO_INITDB_ROOT_PASSWORD (generated), connection_string

Database templates default to 0.5 vCPU and 512Mi memory. Their storage input defaults to 10 GiB and can be adjusted at deploy time.

More seeded templates

The seeded catalog also includes templates such as Directus, OpenClaw, Grafana, Grafana + Prometheus, a full observability stack, NATS, MediaWiki, PgBouncer variants, Mathesar, Temporal, and GitHub Actions runners. Browse the catalog at deployink.com/deploy.

User-created and community templates are coming up.

Deploying templates

List templates

The template_list tool searches and lists available templates. It requires no authentication.

template_list(search: "postgres")

Deploy a template

The template_deploy tool deploys a template and returns connection info.

Tool Call
(
  : "postgres",
  : "my-db"
)
{
  "template_instance_id": "tmpl_abc123",
  "services": [object Object],
  "outputs": [object Object]
}
# List all templates
ink template

# Search templates
ink template postgres

# View template details and variables
ink template info postgres

# Deploy a template
ink template deploy postgres --name my-db

# Deploy with variable overrides
ink template deploy postgres --name my-db --var username=admin --var database_name=myapp

One-click deploy from the project canvas or the template catalog at deployink.com/deploy.

Template features

Auto-generated credentials

Passwords and secrets are randomly generated at deploy time. The agent receives them as outputs — no manual password management required.

Persistent volumes

Every database template attaches a persistent volume at the appropriate data directory. Data survives container restarts and redeployments.

Internal networking

Services in the same project can use returned internal endpoints such as my-db-a1b2:5432. Do not guess the hostname from the display name; read the internal_endpoint returned by template_deploy, template_instance_get, or service_get.

Configurable variables

Templates define required and optional variables with defaults. Override any variable at deploy time to customize the stack.

Connection strings

After deployment, template_deploy returns structured outputs including connection strings, endpoints, and generated credentials. Use template_instance_get later to retrieve the persisted outputs for an existing template instance.

On this page