Render hosting: choose services, understand limits, plan costs

Match the service to the application component

Render organizes application hosting around services. Each service runs on instances whose CPU and memory depend on its compute plan. This makes the application architecture the starting point for selection, rather than a single hosting package.

Public applications and static frontends

Choose a web service for an application that handles public HTTP requests, such as an API or a server-rendered website. Render assigns it a public subdomain and supports custom domains.

Choose a static site when the deployed output consists of files served directly to visitors. Render distributes static sites through a global CDN. A frontend built into static assets and a frontend that needs an application server therefore belong in different service categories, even if their pages look similar to users.

These distinctions follow Render's service-type documentation. Before choosing, identify whether your frontend needs a running server after the build finishes.

Internal services and background processing

A private service accepts traffic from other Render services through an internal hostname without exposing a public URL. A background worker runs continuously, typically consuming queued work, but has no inbound hostname. Cron jobs execute on a schedule and then stop. Workflows organize distributed tasks for uses such as data processing and agent execution.

The practical question is whether a component must receive requests, process work continuously, or execute periodically. Those requirements lead to different Render service types and should remain separate in the cost estimate. Render describes their networking and execution models in the same service reference.

For broader context on deployment responsibilities, the Docker vs Kubernetes guide offers a related starting point when evaluating container-based infrastructure.

Choose the deployment source deliberately

Render supports deployment from a connected Git provider, a public repository address, or an existing Docker image. These routes differ in how updates reach the application.

For a connected Git branch, Render can build and deploy changes when code is pushed. Deploying through a public repository address without Git provider credentials does not support automatic deployments or pull request previews. Existing Docker images also require manual redeployment for updates, according to the web-service documentation.

Choose the route that matches your release process. If repository changes should trigger deployment, use the connected-provider route. If an external process produces the image, account explicitly for the redeployment action rather than assuming that publishing an image updates the running service.

Check the listener before troubleshooting the domain

A web service must listen on host 0.0.0.0. Render recommends using the PORT environment variable, whose default is 10000. If the platform cannot identify a listening port, deployment fails.

Render forwards public traffic to a single HTTP port for each web service. Its load balancer handles incoming HTTPS and passes the request onward over HTTP. These details, documented in the web-service guide, make listener configuration an early check when a build succeeds but the application does not become reachable.

Treat Free instances as evaluation infrastructure

Render's Free compute option has availability, usage, and storage restrictions. The Free instance documentation recommends it for experimentation and hobby projects rather than production applications.

Idle applications need time to return

After 15 minutes with no inbound traffic, a Free web service stops running. A subsequent HTTP request or new WebSocket connection starts it again, with startup taking approximately one minute. A browser may see a loading page during that interval.

For a demonstration, decide whether that first-visit delay is acceptable. For a public application with an immediate-response requirement, evaluate paid compute instead of treating the Free instance as equivalent hosting with a smaller resource allocation.

Each workspace receives 750 Free instance hours per calendar month. Running Free web services draw from that shared allowance; stopped instances do not. Exhausting it suspends the workspace's Free web services until the following month. It is therefore important to assess the whole workspace, not each demonstration in isolation.

Workspace upgrades do not change instance restrictions

A workspace plan controls platform features, while a service's compute plan controls its instance. Paying for a workspace plan does not remove restrictions from a service that remains on Free compute.

Render also excludes persistent disks, scaling to additional instances, and shell access from Free web services. When an application needs one of those capabilities, change the relevant service's compute plan rather than assuming a workspace subscription supplies it. These distinctions are explicit in the Free instance guide.

Design persistence before accepting user data

A Render service's ordinary local filesystem is temporary. On a Free web service, uploads and local database changes disappear after a restart, redeployment, or idle shutdown. Attaching a persistent disk is an option for paid services, but not for Free web services.

For a hypothetical application that accepts uploaded documents, storing those documents only beside the application code would therefore be an unsuitable retention design. Choose a durable storage destination before inviting users to upload files. Render documents the filesystem behavior in its Free hosting documentation.

Free datastores have separate lifecycles

Free Postgres is limited to 1 GB and expires after 30 days. Expiration makes the database inaccessible unless it is upgraded. Render allows a further 14-day upgrade window before deleting it, and Free databases have no backup capability.

Free Key Value has a different risk: its contents exist only in memory and disappear when the instance restarts. Upgrading a Free Key Value instance also discards its existing data. A disposable cache and a database holding records that must be retained consequently require different decisions, even when both initially cost nothing. The Free datastore restrictions explain these behaviors.

Paid Postgres includes continuous backups for point-in-time recovery, while paid Key Value writes its state to disk, according to the datastore overview. Select persistence and recovery capabilities separately from the application's web-service size.

Estimate the application bill, not just the web server

Render's billing model combines workspace fees, service compute, storage, outbound traffic, and build pipeline usage. Its hosting-cost explanation distinguishes continuously running services from scheduled jobs and workflow task compute.

Build the estimate around the actual architecture:

• Include the public application and any continuously running workers.
• Add managed databases, caches, and persistent disks where required.
• Account for scheduled work and workflow execution separately.
• Include outbound traffic and build usage beyond workspace allowances.
• Include additional running instances created for scaling or previews.

Static sites are free to deploy, but their traffic and builds still consume included usage. Free web services also count toward bandwidth and build allowances. Depending on payment and spending-limit conditions, exceeding allowances can cause additional charges, service suspension, or blocked builds. Render explains these outcomes in its Free usage rules.

Use the Render pricing page to assemble the budget for the intended configuration. A workspace fee alone is not the application's total hosting cost. For another hosting evaluation, the Hetzner vs DigitalOcean comparison provides a separate reading path.

Before deploying, record each component's service type, update mechanism, persistence requirement, and compute plan. Then check that the resulting configuration meets the application's response-time and data-retention requirements before moving beyond a disposable trial.