Services and Service Types
Understand Render's core building blocks.
On Render, you deploy and run your code as one or more services:
A given service might represent an API server, a frontend website, an agent workflow, or anything else you want to run.
Render deploys your service's code to one or more instances: containerized environments on Render infrastructure. A service's instance type determines the compute specs (RAM and CPU) for each of its instances.
Service types
Whenever you create a new service, you first specify its service type, based on what your code will do:
Render provides six different service types for running code:
- Web service (most common for your first service)
- Static site
- Private service
- Background worker
- Cron job
- Workflow
You can also create fully managed datastores alongside your other services:
- Render Postgres databases
- Render Key Value instances
- Render Key Value is compatible with virtually all Redis®* clients.
Which service type is right for my code?
Summary of service types
For running code
| Service Type | Description |
|---|---|
|
The most common service type. Dynamic web apps with a public If you're building a public web app using Express, FastAPI, Rails, or something similar, use this service type. To get started, you can create a free instance. | |
|
Websites that consist entirely of statically served assets (commonly HTML, CSS, and JS). Static sites have a public Use static sites to deploy frontends created with frameworks such as: | |
|
Dynamic web apps that don't have a public URL. Private services do expose an internal hostname for receiving traffic from your other Render services over their shared private network. Private services are great for deploying tools like: | |
|
Internal apps that run continuously, often to process jobs from a shared queue. Background workers do not expose a URL or internal hostname, but they can send outbound requests to other service types. Use background workers with a framework like: | |
|
Internal apps that run—and then exit—on a defined schedule. A cron job might run a single bash command, a script with multiple commands, or a compiled executable. Cron jobs do not expose a URL or internal hostname, but they can send outbound requests to other service types. | |
|
Define collections of composable, long-running tasks that execute across distributed compute. Ideal for agents, ETL pipelines, and on-demand background jobs. Workflow task runs do not expose a URL or internal hostname, but they can send outbound requests to other service types. |
For storing data
In addition to the managed datastores below, Render supports attaching a persistent disk to web services, private services, and background workers.
| Service Type | Description |
|---|---|
|
A powerful, open-source relational database. To get started, you can create a free instance that expires after 30 days. Render continually backs up all paid Render Postgres instances to provide point-in-time recovery. Larger instances support additional reliability features like read replicas and high availability. | |
|
An in-memory key-value store that's ideal for use as a job queue or a shared cache. To get started, you can create a free instance. Render Key Value is compatible with virtually all Redis clients. Paid Key Value instances continuously write to disk to persist data across restarts. |
*Redis is a registered trademark of Redis Ltd. Any rights therein are reserved to Redis Ltd. Any use by Render Inc is for referential purposes only and does not indicate any sponsorship, endorsement or affiliation between Redis and Render Inc.