AutoGineer
Generated banner for Render Private Services
Generated logo for Render Private Services

Render Private Services

RenderOfficialCreated by Render

  • Skill
  • Tool integration
  • Cloud and DevOps
  • MIT
  • Low risk
Download ZIP

From the author

Configures Render private services—internal-only apps that accept traffic exclusively from other Render services over the private network. Use when the user needs an internal API, microservice, gRPC server, sidecar, or any service that should not be publicly accessible. Also use when choosing between a private service and a background worker. Trigger terms: private service, pserv, internal service, internal API, microservice, gRPC, not public, private network service.
— the description by Render

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Render private services are non-public applications designed to communicate exclusively over the internal Render network. Unlike web services, they lack a public URL and are ideal for microservices, internal APIs, gRPC servers, and sidecar processes. They support any protocol and can be configured via Blueprints to interact with other services in the same region and workspace using internal hostnames.

What it does

  • Configures services that are unreachable from the public internet.
  • Enables internal communication between services via hostnames and ports.
  • Supports various protocols including HTTP, gRPC, TCP, and WebSockets.
  • Provides integration patterns for microservice topologies and sidecar processes.
  • Defines Blueprint configurations for private service deployment and wiring.
  • Distinguishes between private services and background workers based on port binding.

When to use it

  • When building internal APIs or microservices that should not be publicly accessible.
  • When deploying gRPC, TCP, or other non-HTTP servers.
  • When running infrastructure components like message queues or metrics collectors.
  • When choosing between a service that listens on a port versus a background worker.

Advantages

  • Enhanced security by keeping internal traffic off the public internet.
  • Flexible protocol support beyond standard HTTP.
  • Simplified service discovery via internal hostnames.
  • Seamless integration with other Render services using Blueprint wiring.

Usage examples

“How do I configure a private microservice in my render.yaml?”
The agent provides a Blueprint snippet using type: pserv, defining the runtime, build/start commands, and environment variables for internal connectivity.
“Should I use a private service or a background worker for my queue consumer?”
The agent explains that if the process pulls from a queue and does not listen on a port, a background worker is the correct choice.
“How do I connect my web service to an internal gRPC service?”
The agent demonstrates using the fromService property in the Blueprint to expose the hostport of the gRPC service to the web service.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/render-oss/render-private-services/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip render-private-services.zip -d .agents/skills

Documentation by Render

Render Private Services

Private services are identical to web services except they have no public URL. They are reachable only by other Render services on the same private network (same region + workspace). Use them for internal APIs, microservices, gRPC servers, sidecar processes, and anything that should never face the internet.

When to Use

  • Building an internal API or microservice behind a public gateway

  • Running a gRPC, TCP, or other non-HTTP server that only your services call

  • Deploying infrastructure components (Elasticsearch, ClickHouse, RabbitMQ)

  • Choosing between a private service and a background worker

For public-facing HTTP services, use render-web-services. For services that don't receive any traffic, use render-background-workers.

Before configuring or troubleshooting private connectivity, read references/private-networking.md. Before attaching or changing a persistent disk, read references/persistent-disks.md. When choosing between a private service, web service, and worker, read references/service-types.md.

Private Service vs Background Worker

CriterionPrivate ServiceBackground Worker
Binds to a portYes (required)No
Receives private network trafficYesNo
Sends outbound trafficYesYes
Has internal hostnameYesNo
Use caseInternal APIs, gRPC, TCP serversQueue consumers, async processors

Rule of thumb: If the process listens on a port and other services call it, it's a private service. If it pulls work from a queue and never receives requests, it's a background worker.

How Private Services Work

  • No onrender.com subdomain—not reachable from the internet

  • Reachable at <service-name>:<port> on the private network by services in the same region and workspace

  • Can listen on any port (except restricted system ports)—not limited to HTTP or port 10000

  • Supports any protocol: HTTP, gRPC, TCP, WebSocket, custom binary protocols

  • Same build/deploy lifecycle as web services (build command, start command, pre-deploy)

  • Supports persistent disks and Docker runtime. A disk-backed private service stays single-instance and cannot use autoscaling or zero-downtime deploys; follow references/persistent-disks.md for details.

Connecting to a Private Service

Other services reference a private service via its internal hostname and port:

http://<service-name>:<port>

In Blueprints, wire the address using fromService:

- key: INTERNAL_API_URL
  fromService:
    name: my-api
    type: pserv
    property: hostport

Available fromService properties for pserv:

PropertyValue
hostInternal hostname (e.g. my-api)
portPort the service listens on
hostporthost:port combined (e.g. my-api:10000)

You can also reference a specific env var from the private service using envVarKey instead of property.

Port Binding

Private services must bind to at least one port. If your process does not need to receive traffic, create a background worker instead.

  • Bind to 0.0.0.0 (not 127.0.0.1 or localhost)

  • The PORT env var defaults to 10000; confirm current restrictions in references/private-networking.md before choosing another port

  • For non-HTTP protocols (gRPC, TCP), configure your server on the desired port and tell consumers the hostport

Blueprint Configuration

services:
  - type: pserv
    name: internal-api
    runtime: node
    region: oregon
    plan: starter
    buildCommand: npm ci && npm run build
    startCommand: npm start
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: db
          property: connectionString
Microservices pattern (gateway + internal services)
services:
  - type: web
    name: gateway
    runtime: node
    plan: starter
    region: oregon
    buildCommand: npm ci && npm run build
    startCommand: npm start
    envVars:
      - key: USER_SERVICE_URL
        fromService:
          name: user-service
          type: pserv
          property: hostport
      - key: BILLING_SERVICE_URL
        fromService:
          name: billing-service
          type: pserv
          property: hostport

  - type: pserv
    name: user-service
    runtime: node
    plan: starter
    region: oregon
    buildCommand: npm ci
    startCommand: node server.js
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: db
          property: connectionString

  - type: pserv
    name: billing-service
    runtime: python
    plan: starter
    region: oregon
    buildCommand: pip install -r requirements.txt
    startCommand: gunicorn billing:app
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: db
          property: connectionString

References

DocumentContents
references/private-networking.mdCurrent private-network scope, addresses, ports, discovery, isolation, and troubleshooting
references/patterns.mdMicroservice topology, gRPC setup, and sidecar patterns
references/persistent-disks.mdService-attached disk constraints, configuration, sizing, and snapshots
references/service-types.mdService-type selection and execution models

Related Skills

  • render-web-services — Public HTTP services

  • render-networking — Private network, DNS, service discovery

  • render-background-workers — Services that don't receive traffic

  • render-blueprints — Full render.yaml schema, fromService wiring

  • render-scaling — Compute plans and autoscaling for private services

<!-- shared:documentation-retrieval -->

Current documentation retrieval

Whenever this skill directs you to consult current Render documentation:

  1. Retrieve the linked Markdown document directly with an available URL-fetching tool or HTTP client, such as curl. Do not substitute web-search summaries for the document.

  2. Confirm that retrieval succeeded and returned the expected document, then read its contents. Saving a file or printing its path is not sufficient.

  3. If the request fails or your tool cannot read the Markdown response, open and read the linked HTML version instead.

  4. If neither version can be retrieved, disclose that the current reference is unavailable and follow any topic-specific fallback in the skill. Use bundled guidance only for stable constraints, and do not guess at changeable platform details.

When a task requires multiple references, apply this workflow to each one and distinguish the documents you verified from those that remain unavailable.

<!-- /shared:documentation-retrieval -->

Files

references/service-types.md

<!-- shared:service-types -->

Render service types

Use this guidance when selecting or comparing Render service types, or when a task's architecture depends on the distinction between them. A task that is already unambiguously scoped to one service type does not need this entire overview.

On Render, a service represents code deployed for a particular execution model. Render runs that service on one or more instances, and the service's compute plan determines the CPU and memory available to each instance.

Before choosing a service type, fetch the current service-types reference:

Using the documentation-retrieval workflow in the root SKILL.md, retrieve and read the Markdown reference or its HTML version.

If neither version can be retrieved, use the bundled overview below only for basic service-type selection. State that current platform details could not be verified, and do not guess about changeable capabilities such as supported runtimes, plans, scaling, networking, disks, health checks, deployment behavior, availability, or limits.

Render provides six public service types for running code:

  • Web service: A continuously running server that receives public HTTP traffic and also has an internal hostname for private-network traffic. Use it for dynamic websites, APIs, and other internet-facing server applications.

  • Static site: Built HTML, CSS, JavaScript, and other static assets served publicly from Render's global CDN. Use it only when the deployed application does not require server-side runtime logic.

  • Private service: A continuously running server that receives traffic only over Render's private network. Use it for internal HTTP, TCP, gRPC, or other server processes that need an internal hostname but no public URL.

  • Background worker: A continuously running process that does not receive incoming traffic or expose a public or internal hostname. Use it for queue consumers and other processes that pull or poll for work.

  • Cron job: A command or process that starts on a schedule, performs a bounded unit of work, and exits. Use it for straightforward recurring tasks rather than an always-running process.

  • Workflow: A collection of on-demand tasks executed across distributed compute, with Render handling task queuing, orchestration, and provisioning. Use it when the workload benefits from independently invoked tasks, retries, composition, or parallel execution instead of a continuously running worker process.

Choose based on how the code executes and receives work:

  • Public incoming traffic that requires server-side logic belongs on a web service. Public static assets with no runtime server belong on a static site.

  • An application that needs both public and private ingress remains a web service; use its internal hostname for traffic from other Render services.

  • A process that receives private-network requests belongs on a private service. A process that only initiates connections and pulls work belongs on a background worker.

  • A simple scheduled command that exits belongs on a cron job. An always-running queue consumer belongs on a background worker. On-demand or distributed tasks for which Render should manage queuing and per-run compute belong in a workflow.

Cron jobs and Workflows use invocation-based execution models. The ordinary instance-count and autoscaling model used by continuously running services does not apply to them.

Render Postgres and Render Key Value are fully managed datastores, not general-purpose compute service types for running application code. Use Render Postgres for relational data and Render Key Value for use cases such as shared caching and job queues. An attached persistent disk is a storage feature of certain compute services, not a service type of its own.

After selecting a type, fetch the product article linked from the service-types reference before relying on details such as supported runtimes and sources, plans, scaling, networking, disks, health checks, deployment behavior, scheduling semantics, availability, or limits. These capabilities are not uniform across service types and can change independently.

Human-facing service names do not always map directly to configuration identifiers or structure. When creating or editing a Blueprint, fetch the current Blueprint specification and use its service-type schema instead of inferring fields or values from this overview. In particular, do not assume that every Dashboard service type has a same-named Blueprint type or that managed datastores are declared like compute services.

<!-- /shared:service-types -->

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Python, Needs Node.js

The author says: Render private services (paid plans)

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Render
Publisher
Render (Official)
Source
render-oss/skills · skills/render-private-services · commit b985a63
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Render.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download render-private-services.zip