Storage
Buckets

Buckets store files. Images, videos, PDFs, backups, exports, or any other file your application needs to keep. Unlike a database, buckets are designed for large, unstructured data that you just need to save and retrieve by name.
When to use buckets
Use buckets whenever your app needs to store files that aren’t part of a database. Common examples: users uploading profile photos, your app generating reports as PDFs, or storing backups. Buckets are also how you serve static websites and assets through a CDN.
If you are only storing structured data (like user accounts or product listings), a database is a better fit.
What should I use locally?
- MinIO (an S3-compatible file storage server you can run locally)
Relational Databases

A relational database stores structured data in tables with rows and columns. This is where you keep things like user accounts, orders, products, and any data your app needs to query, filter, or join together. The database makes sure your data stays consistent, for example that a payment is never recorded without a corresponding order.
Spawned provisions a fully managed database instance with automatic backups, encryption, and redundancy so you don’t lose data.
When to use a relational database
If your app has users, accounts, settings, content, or any data that has relationships between different types (users have orders, orders have items), a relational database is the standard choice. Most web frameworks expect one by default.
What should I use locally?
- SQLite is the simplest option and requires no separate server
- PostgreSQL is the most common choice and supports the widest range of features
Secrets Manager

Secrets Manager stores sensitive values that your app needs at runtime but should never be hard-coded or committed to version control. This includes API keys for services like Stripe or OpenAI, database passwords, and any credentials your app uses to connect to external systems.
In the cloud, these values are encrypted and only made available to your application at runtime.
When to use Secrets Manager
Every project uses this by default. Whenever you have a value that would go in a .env file locally (an API key, a database URL, an OAuth secret), it belongs in Secrets Manager in production.
What should I use locally?
- Environment variables via
.envfiles