# Services and Service Types — Understand Render's core building blocks.

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

```mermaid
flowchart LR
  clients@{ shape: procs, label: "<b>Clients</b><br/>(Browsers, etc.)" }
  subgraph "<b>Render</b>"
    webservice["<b>Web Service</b><br/>(API server)"]
    staticsite["<b>Static Site</b><br/>(Frontend)"]
    workflowservice["<b>Workflow Service</b><br/>(Agent)"]
  end
  clients --> webservice;
  clients --> staticsite;
  webservice --> workflowservice;
  class clients secondary;
```

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](your-first-deploy), you first specify its *service type*, based on what your code will do:

[image: Selecting a service type from the New menu]

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?

```mermaid
flowchart TB
    incomingRequests["Will your code receive incoming traffic?"];
    reachableExternal["Will any of that traffic come from the public internet?"];
    static["Does your code perform any server-side logic?"];
    runContinuously["Are you running simple tasks on a schedule?"];
    workerOrWorkflow["Do you want Render to handle job queuing and provisioning?"];
    staticSite["Create a<br/><b><u>Static site</u></b>"];
    webService["Create a<br/><b><u>Web service</u></b>"];
    backgroundWorker["Create a<br/><b><u>Background<br/>worker</u></b>"];
    cronjob["Create a<br/><b><u>Cron job</u></b>"];
    privateService["Create a<br/><b><u>Private service</u></b>"];
    workflow["Create a<br/><b><u>Workflow</u></b>"];
    incomingRequests -->|"<b>Yes!</b>"|reachableExternal;
    incomingRequests -->|"<b>No, it'll run in<br/>the background.</b>"|runContinuously;
    reachableExternal -->|"<b>Yes!</b>"|static;
    reachableExternal -->|"<b>No, only private<br/>network traffic.</b>"|privateService;
    static -->|"<b>Yes!</b>"|webService;
    static -->|"<b>No, I'm only serving<br/>static assets<br/>(HTML, CSS, JS, etc.)</b>"|staticSite;
    runContinuously -->|"<b>Yes!</b>"|cronjob;
    runContinuously -->|"<b>No, I'm running<br/>on-demand workloads.</b>"|workerOrWorkflow;
    workerOrWorkflow -->|"<b>Yes!</b>"|workflow;
    workerOrWorkflow -->|"<b>No, I'll use a framework<br/>like Celery or Sidekiq.</b>"|backgroundWorker;
    class staticSite,webService,backgroundWorker,cronjob,privateService,workflow success;
    class incomingRequests secondary;
    click privateService href "https://render.com/docs/private-services";
    click staticSite href "https://render.com/docs/static-sites";
    click webService href "https://render.com/docs/web-services";
    click cronjob href "https://render.com/docs/cronjobs";
    click backgroundWorker href "https://render.com/docs/background-workers";
    click workflow href "https://render.com/docs/workflows";
```

### Summary of service types

#### For running code

------

###### 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](free#free-web-services).

###### 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](/deploy-vue-js)
- [Hugo](/deploy-hugo)
- [Svelte](/deploy-svelte)
- [Jekyll](/deploy-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-network). Private services are great for deploying tools like:

- [Elasticsearch](/deploy-elasticsearch)
- [ClickHouse](/deploy-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](/deploy-sidekiq-worker)
- [Celery](/deploy-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](disks) to web services, private services, and background workers.

| Service Type | Description |
| --- | --- |
| [*Render Postgres*](postgresql) | A powerful, open-source relational database. To get started, you can create a [free instance](free#free-postgres) that expires after 30 days. Render continually backs up all paid Render Postgres instances to provide [point-in-time recovery](postgresql-backups). Larger instances support additional reliability features like [read replicas](postgresql-read-replicas) and [high availability](postgresql-high-availability). |
| [*Render Key Value*](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](free#free-key-value). 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.

---

##### Appendix: Glossary definitions

###### instance type

Specifies the RAM and CPU available to your service's *instances*.

Common instance types for a new web service include:

- *Free*: 512 MB RAM / 0.1 CPU
- *Starter*: 512 MB RAM / 0.5 CPU
- *Standard*: 2 GB RAM / 1 CPU

For the full list, see the [pricing page](/pricing#services).

Related article: https://render.com/docs/compute-plans.md

###### web service

Deploy this *service type* to host a dynamic application at a public URL.

Ideal for full-stack web apps and API servers.

Related article: https://render.com/docs/web-services.md

###### static site

Deploy this *service type* to host a static website (HTML/CSS/JS) over a global CDN at a public URL.

Related article: https://render.com/docs/static-sites.md

###### private service

Deploy this *service type* to host a dynamic application that is not internet-reachable.

Ideal for internal apps that only your other Render services can access.

Related article: https://render.com/docs/private-services.md

###### background worker

Deploy this *service type* to continuously run code that does not receive incoming requests.

Ideal for processing jobs from a queue.

Related article: https://render.com/docs/background-workers.md

###### cron job

Deploy this *service type* to execute a command or script on a predefined schedule.

Ideal for intermittent tasks like sending email digests or generating reports.

Related article: https://render.com/docs/cronjobs.md

###### Render Workflows

Define collections of long-running *tasks* that execute across distributed compute.

Ideal for agents, ETL pipelines, and background jobs.

Related article: https://render.com/docs/workflows.md

###### Render Postgres

Fully managed PostgreSQL databases that support point-in-time recovery, read replicas, high availability, and more.

Related article: https://render.com/docs/postgresql.md

###### Render Key Value

Fully managed, Redis®-compatible storage ideal for use as a job queue or shared cache.

Related article: https://render.com/docs/key-value.md

###### run

A single execution of a workflow *task*.

A run spins up in its own *instance*, executes, returns a value, and is deprovisioned.

Related article: https://render.com/docs/workflows-running.md