How to Build for the Cloud
When you build an app locally, you make choices about which database to use, where to store files, and how to run your code. Spawned looks at those choices and provisions the corresponding cloud infrastructure.
Cloud services broadly fall into three categories:
Compute
The machines that run your application code and process requests.
Storage
Where your data lives. Databases, uploaded files, and secrets like API keys.
Networking
How users reach your app and how your services communicate internally.
Example: building a fishing map app
1. Start with a web app. You build an app that renders a map of fishing spots with a water temperature overlay. You deploy it to Spawned, which automatically builds a Docker image from your source code and serves it as a container at fishmap.spawned.app. At this point your cloud infrastructure is just one ECS container and the networking that Spawned provisions automatically.
2. Add user accounts and saved spots. Users want to save their favorite fishing spots. That means you need a database. You add SQLite to your project and build the account and saved spots features around it. When you redeploy the updated source code, Spawned detects the database dependency and provisions a managed RDS instance alongside your container. Your app now has compute and a database.
3. Store large map tile files. You want to save historical water temperature data so users can look back over time. Each temperature map is a large collection of tile files, not the kind of data you put in a database. You add MinIO to your local setup, a small server that lets your app store and retrieve files the same way cloud storage works. On the next deploy, Spawned provisions an S3 bucket for these files.
4. Fetch temperature data on a schedule. The temperature data needs to update every hour. That is a scheduled job, not something your web server should handle. You write a small function in your repo that fetches the data. Spawned picks it up and provisions a scheduled cron job that runs on the hour.
You now have a container serving the web app, a database for user data, a bucket for large files, and a serverless function running hourly. All provisioned automatically from your source code.
Spawned provisions networking automatically
These resources are created as part of every deployment. You don’t need to configure them.
- Load Balancer routes traffic to your containers
- Networking isolates your infrastructure from other tenants
- CDN caches static content closer to your users
- Container Registry stores your Docker images
- SSL Certificates enables HTTPS on your domains
For concrete examples of what you can build, check out the demos.
Service reference
| Service | AWS | GCP | Azure | Auto-detected | Configurable post-deploy |
|---|---|---|---|---|---|
| Containers | ECS | × | × | Yes | No |
| Serverless | Lambda | × | × | Yes | Schedule, runtime, memory, timeout |
| Kubernetes | EKS | × | × | YAML upload only | No |
| Buckets | S3 | × | × | Yes | No |
| Relational Databases | RDS | × | × | Yes | No |
| Secrets Manager | SSM Parameter Store | × | × | Included with every project | Yes |
| Load Balancer | ALB | × | × | Automatic | No |
| Networking | VPC | × | × | Automatic | No |
| CDN | CloudFront | × | × | Automatic | No |
| Container Registry | ECR | × | × | Automatic | No |
| SSL Certificates | ACM | × | × | Automatic | No |
The networking services above are provisioned automatically with every deployment and don’t require configuration.