Docs/Operate
Deployment
Deploy the dashboard, trusted Rust backend and private SableDB as independent services with one reviewed configuration contract.TLS terminated · stateless · independently scalable
Passkeys · policy · Connect/gRPC · health checks
Persistent volume · encrypted recovery · no public database
One-click Railway deployment
The Railway template creates the three services inside one project, generates the master key and bootstrap token, links the backend and SableDB over Railway's private network and attaches the persistent volume. Dashboard and backend remain separately scalable. Runtime policy uses the same versioned YAML contract as every other platform, supplied through Railway's multiline RUSTYAUTH_CONFIG_YAML variable; credentials remain separate sealed variables.
RustyAuth 1.0.0 supports the server, container and web topology. Pin exact image digests and qualify ingress, egress, secrets, backups and recovery for your environment.
Container deployment
The supplied containers run as non-root users. The backend automatically reads /etc/rustyauth/config.yaml. Mount the non-secret document read-only, inject credentials with environment variables or secret files, keep the backend and SableDB on a private network, and attach a durable volume at SableDB's documented data path. Publish only the dashboard unless an integration explicitly requires a public realm API.
Kubernetes and Civo K3s
Use the integrated chart for a self-contained app environment, the Fleet chart for the central dashboard and control plane, and the lightweight realm chart once per managed project environment. The charts retain SableDB claims, enforce the one-writer update strategy and default to Traefik ingress. See the copy-ready Helm guide.
Promote configuration safely
Keep one rustyauth.yaml per environment, validate every document in pull requests, preview the platform IaC change, then deploy them together. RustyAuth refuses unknown fields or invalid policy before binding its listener. Resources marked Managed by YAML in the dashboard must be changed through this deployment path, which prevents interactive drift from becoming a hidden second source of truth. See the configuration-as-code guide for source precedence, Railway variables, mounted secrets, webhooks and backup schedules.
Scaling
The authentication service is lightweight and can scale vertically with predictable resource use. Version 0.1 intentionally supports one writer replica while cross-process identity mutations are qualified.
Backup and recovery
Enabling the YAML backup policy and supplying its separate credentials enables authenticated logical snapshots at startup and at the configured interval. Each snapshot contains the complete server-side namespace for that deployment. A Fleet backup protects central hierarchy and audit state; every managed realm retains a separate identity backup. The default immutable profile requires Versioning, compliance-mode Object Lock and provider-side encryption. The explicit portable profile retains application encryption and read-back verification for providers without those APIs, but does not claim WORM retention. Operators can run backup create, backup list, backup status, backup verify <object-key> and backup restore <object-key>. Restore requires an empty SableDB namespace and invalidates sessions by default.
Bucket credentials are not evidence of recoverability. Restore a selected object into a clean volume, run doctor, and verify a real passkey sign-in on a regular schedule.
Use the backup and key-rotation runbook for the complete operator workflow and safe key-overlap rules.
Fleet deployment
Deploy Fleet as a separate three-service project: Dioxus Fleet dashboard, Fleet control-plane API and a private Fleet SableDB. Each managed environment keeps a separate realm deployment and recovery boundary. See Fleet control plane and the complete Railway topology reference.