Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Tutorial 31: SaaS deployment preparation for AWS or GCP

This guide prepares a generated SaaS application for a cloud deployment. It is not an end-to-end production certification: identity, network policy, database operation, secrets, billing and recovery remain deployment responsibilities.

1. Materialize and verify the SaaS starter

Install the published 13.0.0-alpha.4 CLI with its exact version (Cargo never selects a prerelease on its own, and the v12 line reached end of life on 16 October 2026), then generate deterministically. Do not substitute the moving main branch for an immutable release artifact:

cargo install cargo-rullst --version =13.0.0-alpha.4 --locked
cargo rullst new my_cloud_saas --default --blueprint saas --docker
cd my_cloud_saas
cargo fmt --all -- --check
cargo clippy --all-targets --all-features -- -D warnings
cargo test --all-features

Review every generated route, access policy, migration and environment placeholder before supplying live credentials.

2. Supply secrets outside source control

Use AWS Secrets Manager, Google Secret Manager or an equivalent deployment boundary for values such as APP_KEY, DATABASE_URL, provider keys, webhook secrets and, if you use encrypted model fields, RULLST_ENCRYPTION_KEY. Do not bake .env into an image (the generated .dockerignore keeps .env and .env.* out of the build context).

Set RULLST_ENV=production and make startup fail when a required production adapter or credential is missing. Empty and mock_* provider credentials are for deterministic offline development, not live operation.

3. Build and scan the exact image

docker build --pull --tag my-cloud-saas:<git-sha> .
docker inspect my-cloud-saas:<git-sha>

Pin the deployed image by digest. Run the application’s tests and a container scanner against the exact candidate. The CLI’s deploy command writes a Dockerfile, compose.yaml and Caddyfile for a Linux VM (see Deploy to a Linux VM); AWS App Runner/ECS and Google Cloud Run configuration remains explicit cloud work.

4. Configure the cloud boundary

For AWS or GCP, define and review:

  • private database connectivity, TLS and least-privilege credentials;
  • trusted proxy handling and the application’s external origin policy;
  • ingress authentication, rate limits, body limits and request timeouts;
  • readiness/liveness behavior and a bounded shutdown grace period;
  • immutable image rollout and a tested rollback procedure;
  • logs, metrics and alerts that avoid secrets and unnecessary PII.

Managed services have provider-specific scaling floors, quotas, cold starts and costs. Verify current provider documentation and load-test your selected region and topology rather than assuming scale-to-zero or a request rate.

5. Exercise stateful recovery

Before production traffic, rehearse migrations, backup, restore, webhook replay, field-encryption key rotation, a failed rollout and database unavailability. Health endpoints only report the checks implemented by the application; they do not create zero-downtime deployment by themselves.