Services and Service Types – Render Docs

On Render, you deploy and run your code as one or more services:

Render deploys your service's code to one or more instances: containerized environments on Render infrastructure. A service's compute plan determines the CPU and RAM 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?

Will your code receive incoming traffic?

Will any of that traffic come from the public internet?

Does your code perform any server-side logic?

Are you running simple tasks on a schedule?

Do you want Render to handle job queuing and provisioning?

Summary of service types

For running code

Service Type	Description
Web service	The most common service type. Dynamic web apps with a public `onrender.com` subdomain for receiving HTTP traffic. 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.
Static site	Websites that consist entirely of statically served assets (commonly HTML, CSS, and JS). Static sites have a public `onrender.com` subdomain and are served over a global CDN. Use static sites to deploy frontends created with frameworks such as: - Vue.js - Hugo - Svelte - Jekyll
Private service	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: - Elasticsearch - ClickHouse
Background worker	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: - Sidekiq - Celery
Cron job	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.
Workflow	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
Render Postgres	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.
Render Key Value	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.