Choose a service
Match each part of your application to the right Openstead service.
A service is a separately configured and deployed part of your application. A project groups related services, such as a frontend, API, worker, and database. Openstead provides the infrastructure; you connect your code and choose how it runs.
Compare service types
| Service | Use it for | How it runs | Public URL |
|---|---|---|---|
| Web service | APIs, server-rendered websites, application backends | A continuously running application process | Yes |
| Static site | HTML, CSS, JavaScript, client-rendered frontends | Files produced by a build | Yes |
| Private service | Internal HTTP services and application components | A running process reachable through private networking | No |
| Background worker | Queue consumers and asynchronous processing | A continuously running worker process | No |
| Cron job | Periodic reports, cleanup, scheduled application commands | A fresh execution on a schedule | No |
| PostgreSQL | Relational application data | A managed database with persistent storage | Private connections |
| MySQL | MySQL applications, including Laravel | A managed database with persistent storage | Private connections |
| Key Value | Redis-compatible caches, queues, shared state | A managed Redis-compatible service | Private connections |
Choose between a web service and a static site
Choose a web service when requests execute server code. Next.js server rendering, Django views, Laravel routes, and Express APIs need a running server.
Choose a static site when your build produces a directory that can be served as files. Vite frontends and exported Next.js sites are common examples. A static site cannot execute PHP or open a private database connection from the browser.
A frontend and API can be separate services. Configure the frontend with the API's public URL and configure the API's CORS policy for the frontend's origin.
Build an application from several services
For a typical application:
- Create a project.
- Add a database in the intended environment.
- Deploy the API as a web service and connect it to that database privately.
- Add a worker if the application processes jobs outside HTTP requests.
- Add a static frontend or serve the frontend from the web service.
- Attach custom domains to the public services.
Deploying one service does not automatically deploy the others. Review each service's source, variables, plan, and deployment status. Use a Blueprint when you want to describe related resources together.
Keep application data outside the container filesystem
Code and dependencies belong in the deployment artifact. Store relational data in a database, and store uploaded files in object storage or a persistent disk. Files written only to a running container can disappear when it is replaced.
For your first application, follow Deploy your first service.