Choose a service type based on whether your code receives requests, runs continuously, or exits after completing a task. Choose the runtime separately: it determines how Bex builds or obtains the artifact to deploy.
Choose a workload
| Workload | Use it for | Incoming connections | Blueprint configuration |
|---|---|---|---|
| Web service | Public APIs and server-rendered websites | HTTP through configured public routing | type: web |
| Private service | An internal API or network server | Internal service address; no public ingress | type: pserv |
| Background worker | Queue consumers and continuous processing | No service endpoint | type: worker |
| Cron job | Scheduled commands that exit | No service endpoint | type: cron, plus schedule |
| Static site | Built HTML, CSS, JavaScript, and other files | Shared static server with configured public routing | type: web, runtime: static |
A static site cannot run server-side request handlers. If your framework needs a server for rendering or API routes, deploy it as a web service instead. A worker can make outbound connections to a database, queue, or API without exposing an inbound endpoint.
Choose a runtime
For web/private services, workers, and cron jobs:
- Dockerfile in Git: use
runtime: dockerand a repository URL. - Prebuilt container: use
runtime: imageandimage.url. - Native build: select
node,python,go,ruby,rust, orelixir, and supply build and start commands appropriate to your application.
See Docker deploys and How deploys work. Build and runtime settings are independent of whether a service is public.
Store application data
Use PostgreSQL for relational data and Key Value
for a Redis-compatible cache or queue. PostgreSQL declarations live under
databases: in a Blueprint. Key Value uses type: keyvalue under services:.
These managed datastores have their own lifecycle and connection settings.
Configure and deploy
Use the dashboard creation flow or declare one or more resources in a
render.yaml Blueprint. That guide covers the required
API credentials, validation, and deployment commands.
For example, this selects a private HTTP service built from a Dockerfile:
services:
- name: internal-api
type: pserv
runtime: docker
repo: https://github.com/your-org/internal-api
branch: main
autoDeployTrigger: offReplace the repository URL with your own application. Its server should listen
on 0.0.0.0:$PORT. The service has an internal address, with no public ingress;
use the private network guide to connect callers.
Blueprint names differ from Kubernetes App type names:
| Blueprint | Kubernetes App spec.type |
|---|---|
web | web_service |
pserv | private_service |
worker | background_worker |
cron | cron_job |
web with runtime: static | static_site |
Do not use type: private or type: static in a Blueprint. A service's type
is fixed after creation. To change the workload type, create a replacement,
verify its behavior, move callers or traffic, and retire the old service when
it is no longer needed.
Scale the right resource
For long-running services, the instance count controls concurrent processes; scaling explains manual and automatic policies. A cron schedule controls when work starts, not how many replicas run. Static sites publish files to shared serving infrastructure rather than running a dedicated application process for each site.
Render has additional product surfaces, including Workflows. Their presence in Render's service catalog does not imply Bex support; consult compatibility before migrating.