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 as a function with a domain connection, reachable at fishmap.spawned.app. Nothing runs between requests, so the app costs nothing while idle. At this point your cloud infrastructure is one function and a hostname.
2. Add user accounts and saved spots. Users want to save their favorite fishing spots. That means you need a database. You add a Database component to your project — from the canvas, the CLI, or by asking your coding agent — and connect it to your function. On the next deploy Spawned provisions a managed RDS instance and injects the credentials into your app. 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 a bucket component and connect your function to it, and Spawned provisions the S3 bucket and hands your app its name.
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 that fetches the data and add it as a Function component with an hourly schedule. Spawned provisions a scheduled cron job that runs on the hour.
You now have a function serving the web app, a database for user data, a bucket for large files, and a second function running hourly. All declared in one infra.json and provisioned by Spawned. If the web app later needs to hold connections open or run long requests, it moves to a container and the rest stays as it is.
Spawned Provisions Networking Automatically
These resources are created as part of every deployment. You don’t need to configure them.
- Networking places your workloads in a network, with security groups scoping access to each project
- Container Registry stores your Docker images
- SSL Certificates enables HTTPS on your domains
To serve public traffic, connect your domain to the component that answers requests: a function directly, a Load Balancer in front of containers, or a CDN for static content.