Built-ins

Each entry under managed is <name>: { type: <type>, ...options }. The name is the host inside the sandbox (db:5432), so it can't also be a service's name. Each sandbox gets its own instance of every entry, with its own generated credentials.

Protocols

They all speak standard protocols, so moving from a hosted Postgres, Redis, S3 or ClickHouse is a URL change. There is no MySQL, MongoDB or RabbitMQ: run one as a service (image: mysql:8.0, ports: { mysql: 3306 }), and list it in a migration job's depends_on (see jobs). Celery, BullMQ and Sidekiq run on Redis.

Where each built-in runs

Postgres

Postgres behaves like Google Cloud SQL, which staging and production use. Your app's user owns its database but is not a superuser: it has CREATEDB and CREATEROLE and is a member of cloudsqlsuperuser. Cloud SQL's contrib extensions are available, vector (pgvector) included, and the app can create them. Any other extension, or a migration that needs a superuser, fails in the sandbox, before it would fail in production. It accepts TLS and plain connections. The sandbox certificate is self-signed: a client that doesn't verify it (ssl: { rejectUnauthorized: false }, libpq's sslmode=require) connects, and one that does needs sslmode=disable in sandboxes.

S3 storage

S3 storage speaks the S3 protocol, with each bucket in buckets created per sandbox.

• Use public_endpoint for any URL a browser follows, such as presigned uploads and downloads. Your services can reach it too, so it works everywhere.
• With the AWS JS SDK v3, set forcePathStyle: true and requestChecksumCalculation: 'WHEN_REQUIRED'.
• Each listed bucket allows GET, PUT, POST and HEAD from the sandbox's own public URLs (CORS), which presigned browser uploads need. To set other rules, call PutBucketCors from a deploy job.

Email

Email is SMTP. url is smtp://[user:password@]host:port; in sandboxes it is smtp://<name>:1025, with no TLS and an empty user and password. The inbox accepts any user and password, so an app that always sends credentials works with placeholders such as SMTP_USER: sandbox. All mail the app sends lands in the sandbox's inbox, whatever the recipient. Read it with parity inbox.

If your app sends through a provider's HTTP API, switch it to SMTP: Resend, Postmark, SendGrid, Mailgun and Amazon SES all accept SMTP, so one code path sends in sandboxes and in production.

Auth

Auth is an OpenID Connect provider with its own users per sandbox. Its token endpoint accepts the client secret either way OAuth allows (client_secret_basic or client_secret_post), so any OIDC library works with its defaults.

managed:
  auth:
    type: auth
    redirect_uris: [{ service: web, path: /auth/callback }]
    initiate_login_uri: { service: web, path: /login }

redirect_uris registers your app's callbacks. initiate_login_uri is where sign-in links land. Create users with parity auth user create and get a one-time sign-in link with parity signin <email>.

Certificates

An X.509 certificate issued by the sandbox's own certificate authority, for document signing, mutual TLS or a TLS listener inside the sandbox.

managed:
  signing: { type: certificate, keystores: [pkcs12] }
services:
  web:
    env:
      SIGNING_P12:          ${signing.pkcs12_file}
      SIGNING_P12_PASSWORD: ${signing.pkcs12_password}

• The _file attributes are file paths. A service (and its jobs) that references the entry gets the files mounted read-only under /var/run/secrets/parity/<name>/.
• ca_file is the sandbox's own root, so two sandboxes never trust each other's certificates.
• common_name (default <name>, sandbox <id>) and dns_names may use ${sandbox.id} and ${sandbox.domain}. duration is 1h to 8760h, default 2160h.
• There's no standard variable name for a certificate, so depends_on is refused for this type. Name the variables your app reads.