Running In Production

Running In Production

There are two ways to run Seamless Auth in production. The managed offering hosts the auth instance for you. Self-hosting means you provision and operate the stack yourself.

This page previously documented an AWS dev-tier deploy and destroy command flow. That flow is not in the current ../seamless-cli source, so it is no longer described here as shipped.

---

Managed hosting

On the managed path, Seamless runs the auth instance for you. You create an application in the portal at https://dashboard.seamlessauth.com, pick a plan, and Seamless provisions a dedicated hosted instance at https://<your-app-id>.seamlessauth.com. You point the SDKs at that URL and a portal-issued service token.

On this path you do not provision Postgres, manage signing keys, or run the auth server. See the Managed Quickstart.

---

Self-hosted CLI surface today

For self-hosting, the public CLI command surface is:

seamless init [project-name]
seamless check
seamless bootstrap-admin [email]
seamless verify
seamless login
seamless profile <list|add|use|remove>
seamless --help
seamless --version

The CLI also exposes whoami, logout, sessions, and the admin commands config, users, and org against a configured instance. See the CLI command reference for the full surface.

There is no seamless deploy or seamless destroy implementation in ../seamless-cli.

Note

A managed init flow, where seamless init connects a scaffolded app to your hosted managed instance instead of hardwiring localhost. Running seamless init when logged in will default to the managed path, adding --local will force the self-hosted stack. at localhost. Running seamless init while not logged in and in an non-empty directory will print ‘log in first’ and exit.

---

What the CLI can prepare today

seamless-cli can generate a local self-hosted project with:

• React web starter
• Express API starter
• Seamless Auth API in Docker or local-source mode
• optional admin dashboard in Docker image or source mode
• Docker Compose wiring
• local secrets and service URLs
• seamless.config.json

That gives you a production-shaped local stack, but it is not a hosted deployment workflow.

---

What self-hosted operators still own

If you self-host, until deployment automation ships you own:

• hosting the auth API, application API, web app, and optional admin dashboard
• provisioning Postgres
• setting stable production secrets
• configuring JWKS signing keys
• configuring HTTPS, CORS, origins, cookie domain, and proxy headers
• managing OAuth provider callback URLs and provider secrets
• monitoring, logging, alerting, backup, and restore testing

Use Environment Variables, System Config Reference, and Cookie, Session, And Token Reference when planning those deployment surfaces.

The managed offering handles these for you.

---

Documentation Rule

When documenting deployment work:

• do not describe deploy or destroy as shipped unless those commands exist in ../seamless-cli
• label future deployment flows as planned or in progress
• tie infrastructure claims to current source code or generated files
• keep operator-owned production hardening separate from CLI-generated local setup

---

Next Step

Continue to Environment Variables.