Render Blog

You push code, Render deploys it. Zero downtime, health checks, built-in rollbacks, no fuss. For most teams, that workflow is perfect.

But what if you have multiple services that need to deploy together? What if you want to test new code with real traffic before going all-in?

Using SuperPlane, an open-source workflow engine for DevOps automation, we connected Render with Cloudflare, Dash0, and GitHub Actions to build a fully automated blue/green canary pipeline. New versions deploy to an idle environment, receive a percentage of live traffic, run through verification checks, and either promote automatically or roll back without manual intervention.

Here's how it works.

What blue/green actually means

Two identical environments. One is live, one is idle. New code goes to the idle environment. You verify it works. Then you switch traffic over.

The old version stays running. If the new code is broken, you switch back. No rebuild, no redeploy. Instant recovery.

Render's zero-downtime deployment model already implements the core blue/green property at the single-service level: a new instance boots alongside the old one, traffic shifts once the new instance is healthy, and the old instance shuts down gracefully.

What this pipeline adds is canary traffic shaping and coordinated cutover across multiple services.

Why add canary?

Even with blue/green, switching traffic is usually all-or-nothing. Canary deployments add a middle step: send 5% of traffic to the new version first. If error rates stay low, gradually ramp traffic up to 100%. If something breaks, route it back before most users notice.

Deploy and verify, not deploy and hope.

The experiment

Our application runs on Render: an API, a web frontend, and a background worker. We duplicated each service to create blue and green environments. Six Render services total.

Then we connected four tools to orchestrate them:

• Render: hosts and deploys all six services
• Cloudflare: routes traffic between blue and green with configurable weights
• Dash0: monitors synthetic checks and real-time PromQL error rates
• GitHub Actions: runs smoke tests against the newly deployed environment

This setup doesn't eliminate complexity. It centralizes it.

Instead of scattered scripts and manual runbooks, deployment logic lives in a single visual pipeline where every step, decision, retry, and rollback path is visible and auditable.

Blue/Green Canary Deploy Pipeline

Push to main. SuperPlane checks which environment is live, deploys to the other one, shifts 30% of traffic, runs verification checks, and either promotes to 100% or rolls back automatically.

No one touches a button.

What it looks like running

Here's the canary verification phase mid-run. Smoke tests, Dash0 synthetic checks, and error-rate queries execute in parallel while 30% of traffic hits the new environment.

Blue/Green Deploy Live Canvas with Canary Traffic Shift and Health Verification

And here's the decision point: all checks passed, so the pipeline promotes the new environment to 100% traffic and saves the updated deployment state.

Blue/Green Deploy Live Canvas with Promote or Rollback

The rollback path (bottom) shows a previous run where verification failed. SuperPlane automatically reverted each service and restored the previous Cloudflare traffic weights. Both success and rollback paths remain visible in the same workflow canvas.

How this orchestration helps

Render's built-in zero-downtime deployments already support many blue/green deployment properties for individual services. SuperPlane extends that model with orchestration across services, progressive traffic shifting, and automated rollback logic.

Multi-service coordination

This pipeline coordinates deployments across multiple services and multiple external systems.

SuperPlane integrates natively with Render, Cloudflare, Dash0, and GitHub, passing deployment data between steps without custom glue code.

More importantly, it manages sequencing:

1. Deploy service B v2
2. Verify health
3. Deploy service A v2
4. Verify again
5. Shift traffic

If something fails midway through the rollout, the workflow rolls back the entire deployment state, not just the failing service.

Long-running workflows

After shifting traffic, the pipeline waits before querying Dash0 for real production error rates.

That soak period is configurable, ranging from minutes in staging to hours in production.

CI systems can technically implement this with sleep loops, but they are not designed for workflows that pause, resume, branch, and react to external signals over long periods of time.

Parallel fan-out / fan-in

Verification tasks run concurrently:

• Smoke tests
• Synthetic monitoring
• Error-rate analysis

The workflow waits for every check to complete before making a deployment decision. One failure triggers rollback automatically.

Conditional routing

The deployment path branches dynamically based on runtime state.

• If blue is live, deploy green
• If green is live, deploy blue
• If verification succeeds, promote traffic
• If verification fails, roll back

Each branch evaluates real deployment data from previous steps and routes execution accordingly.

Observability beyond smoke tests

Smoke tests validate the scenarios you anticipated.

Observability catches the ones you didn't.

During testing, we saw smoke tests pass while production traffic still triggered failure modes that weren't covered by test cases. Dash0 detected elevated 5xx rates during the canary phase, the error threshold crossed 1%, and SuperPlane rolled the deployment back automatically.

Automated rollback

Render already provides API-driven and dashboard-based rollbacks.

In this workflow, SuperPlane automates the rollback decision itself. When verification fails, it:

1. Calls the Render rollback APIs for each service
2. Restores Cloudflare traffic weights
3. Returns the system to the last healthy deployment state

No manual intervention required.

Other challenges with blue/green

We focused primarily on deployment orchestration and traffic switching, but blue/green deployments come with additional trade-offs.

Shared databases

Both environments share the same database, so schema migrations need to remain backward-compatible during rollout windows.

Infrastructure cost

Running two copies of every service increases infrastructure cost. One common optimization is scaling the idle environment down after promotion and scaling it back up before the next deployment.

Wrapping up

Can you build blue/green canary deployments on Render? Yes.

Render provides the building blocks:

• Fast zero-downtime deployments
• Health checks and deploy status tracking
• API-driven and one-click rollbacks

SuperPlane connects those primitives with Cloudflare, Dash0, and GitHub Actions into a workflow that deploys, verifies against real traffic, and rolls back automatically.

Try it yourself

We packaged the entire workflow as a reusable template you can import and run.

Option 1: SuperPlane Cloud

1. Sign up at app.superplane.com (free tier available)
2. Open Browse Templates
3. Select the Blue/Green Deploy template
4. Connect your integrations (Render, Cloudflare, Dash0, and GitHub)
5. Configure the workflow components for your services and environments

Option 2: Self-hosted

SuperPlane is fully open source.

Follow the installation guide to run it on your own infrastructure, then import the same workflow template.

What we used

This pipeline uses Render, Cloudflare, Dash0, and GitHub Actions, but the architecture is flexible.

You can swap components to match your own stack:

• Different hosting providers
• Different CDNs or traffic routers
• Different observability platforms

The workflow structure remains the same.

The template also includes inline annotations explaining each phase so you can adapt the deployment strategy to your own environment.

SuperPlane is open source, and Render's APIs make it easy to build advanced deployment workflows on top of the platform.

If you build something with it, share it with us on Superplane's Discord.

Dedicated IPs for your services on Render

Today we're launching Dedicated IPs, giving you static, exclusive outbound IP addresses for your Render services. Your dedicated IPs are exclusive to your workspace, so you can reliably allowlist your Render services with external providers, databases and sensitive systems.

Each dedicated IP set provides three static IPv4 addresses for a workspace or selected environments in a single region. Once enabled, all outbound traffic from services in scope routes through those IPs exclusively.

Meet stricter security and compliance requirements

As Render customers scale their production workloads, they need a stronger security posture for the systems those workloads interact with. Shared outbound IPs work for many cases, but if you have stricter security requirements, you need more precise control over your traffic to sensitive services. This is especially relevant for companies in regulated environments where strictly controlled egress is a hard requirement for compliance, security, and governance.

Dedicated IPs make it easier to support those traffic flows while managing your configuration directly within the Render Dashboard.

Flexible by design, simple to get started

Each dedicated IP set covers one region and provides three static IPv4 addresses, one per availability zone, giving you redundancy across the region without managing multiple sets.

Scoping is flexible. Apply a dedicated IP set to an entire workspace or pin it to specific environments. Your production, staging, and development environments have different trust levels and access needs. Dedicated IPs let you reflect that at the network level, whitelisting production independently from staging and keeping lower-trust environments from sharing the same network identity as production. You can also update your scope by adding or removing environments at any time.

Dedicated IPs are available to all customers on Pro, Scale, or Enterprise plans, including legacy* Professional and Organization plans. Each dedicated IP set is $100 per month, no contract required.

Manage everything through the Render Dashboard, REST API or Terraform provider.

Get started with Dedicated IPs

Explore the full list of capabilities and setup instructions in our documentation.

If you have questions, concerns, or additional needs that are not currently addressed, please reach out to our support team in the Render Dashboard.

Note: At launch, each dedicated IP set covers a single region. If you're running services across multiple regions, you'll need a separate set for each. We're actively working to expand what's possible. Follow our changelog to stay updated.

*Check your current usage and opt into a new plan today to reduce your bill, or wait for the automatic conversion on August 1st, 2026 (Professional to Pro, Organization to Scale). Review the announcement of our new workspace pricing model for a full breakdown of the changes.

This guest post is kindly contributed by LlamaIndex, who help teams automate document processing with agent-powered OCR.

Document processing at scale is hard. A single slow PDF can block your server and degrade unrelated requests. Parsing, classifying, and extracting structured data from documents needs to be reliable, retryable, and non-blocking.

This post walks through a reference architecture for a document processing pipeline that pairs LlamaParse for document intelligence with Render Workflows for scalable, distributed task execution.

A monolithic problem

The most basic approach to document processing usually looks like this:

1. A client uploads one or more files to a server.
2. That same server also handles processing the uploaded file(s).
3. After processing completes, the server persists the results and returns them to the client.

This approach works for handling small workloads, but it hits a wall at any meaningful scale: a single massive file can block threads, trigger parsing failures, or time out requests. To make matters worse, just one failure can mean re-running an entire job from scratch.

To help our application scale with the work we give it, we can separate its two primary concerns into a proper pipeline:

• Restrict our server's scope to receiving uploads and streaming progress to clients.
• Spin up isolated, retryable workflow tasks to perform individual processing steps with LlamaParse and LlamaCloud.

Architecture overview

Our scalable pipeline consists of three services deployed on Render:

• Web service: This is our server. It accepts file uploads or URL downloads, streams real-time progress via Server-Sent Events, and exposes search and RAG endpoints.
• Workflow: This is our orchestration layer. It defines and executes five discrete tasks, each with a specific instance type, timeout, and retry policy.
• Postgres database: This stores the results of our document processing.

Whenever a user uploads a document, our web service reads the bytes and dispatches them to the first workflow task run. From there, everything executes asynchronously:

Diagram showing the processing pipeline architecture

Example code for this project is available on GitHub.

Dispatch with Render Workflows

Our workflow service defines five tasks that each handle a different step of our document processing pipeline: upload_to_llamacloud, classify_document, parse_document, extract_fields, and store_results.

In our workflow code, we define each task as a TypeScript function with the Render SDK and configure its resource plan, timeout, and retry policy:

export const parseDocument = task(
  {
    name: "parse_document",
    plan: "standard",
    timeoutSeconds: 600,
    retry: { maxRetries: 2, waitDurationMs: 5000, backoffScaling: 2 },
  },
  async function parseDocument(fileId: string) { ... }
);

In our web service, we again use the Render SDK to dispatch our workflow tasks and poll for results:

async function startAndWait(taskPath: string, params: unknown[]) {
  const started = await render.workflows.startTask(
    `${WORKFLOW_SLUG}/${taskPath}`, params
  );
  while (true) {
    await new Promise((r) => setTimeout(r, POLL_INTERVAL_MS));
    const details = await render.workflows.getTaskRun(started.taskRunId);
    if (details.status === "completed") return details.results?.[0] ?? null;
    if (details.status === "failed" || details.status === "canceled") {
      throw new Error(`Task ${taskPath} ${details.status}: ${details.error}`);
    }
  }
}

Each task run executes in its own instance, which means parsing a large PDF gets its own isolated environment. If a run fails, its retry policy automatically handles exponential backoff, with no manual logic required.

Document intelligence with LlamaCloud

Each workflow task delegates document intelligence to LlamaCloud, using shared client configuration for authentication:

import LlamaCloud from "@llamaindex/llama-cloud";

export function getLlamaClient(): LlamaCloud {
  if (!_client) {
    _client = new LlamaCloud({ apiKey: process.env.LLAMA_CLOUD_API_KEY });
  }
  return _client;
}

Classification

The classify_document task sends the uploaded file to LlamaCloud Classify, comparing it against a set of document type rules:

const job = await client.classify.create({
  file_input: fileId,
  configuration: { rules: CLASSIFICATION_RULES },
});

Rules describe document types such as invoices, contracts, resumes, financial statements, and more. LlamaCloud returns the best match, a confidence score, and human-readable reasoning.

Parsing with LlamaParse

The parse_document task uses LlamaParse's agentic tier, which handles 130+ file formats and returns clean markdown and plain text:

const result = await client.parsing.parse({
  file_id: fileId,
  tier: "agentic",
  version: "latest",
  expand: ["markdown_full", "text_full"],
});

The agentic tier handles complex layouts (tables and charts, multi-column text, images, etc.) and returns structured markdown ready for downstream processing.

Structured extraction with LlamaExtract

Once the document type is known, the extract_fields task runs LlamaExtract against a predefined JSON Schema, or generates one on the fly for unknown types:

const result = await client.extract.run({
  file_input: fileId,
  configuration: {
    data_schema: schema,
    cite_sources: true,
    confidence_scores: true,
  },
});

For an invoice, this yields structured fields like invoice_number, vendor_name, line_items, and total_amount. For unknown document types, LlamaExtract generates an appropriate schema automatically using a prompt.

Storage and semantic search

Finally, the store_results task writes results to Postgres and optionally indexes the parsed text into a LlamaCloud-managed pipeline:

await client.pipelines.documents.upsert(PIPELINE_ID, {
  body: [{
    id: `doc-${documentId}`,
    text: textToIndex,
    metadata: { document_id: documentId, filename, doc_type: classification.docType },
  }],
});

Once indexed, documents are searchable with embeddings, hybrid retrieval, and reranking, all managed by LlamaCloud. The web service exposes /search and /ask endpoints backed by this pipeline.

Live progress streaming

While tasks run, the web service streams real-time status to the frontend via Server-Sent Events:

yield sse("status", { phase: "parsing", tools: ["LlamaParse", "Render Workflows"] });

// ... task runs in the workflow service ...

yield sse("parsed", { pageCount: parsed.pageCount, markdownPreview: "..." });

Users see each stage complete in real time (uploading, classifying, parsing, extracting, storing) without any polling from the client. Here's the full pipeline:

Timeline showing the full document processing pipeline

Deploy it yourself on Render

To run this architecture yourself, follow the deployment guide in the project README. At a high level, you'll:

• Deploy the web service and Postgres database via the repository Blueprint
• Create the workflow service manually in the Render Dashboard (npm install && npm run build, then node dist/tasks/index.js)
• Set environment variables for the web and workflow services to connect to the Postgres database and LlamaCloud

Go to GitHub

Key takeaways

• Render Workflows gives each stage of our processing pipeline its own compute plan, timeout, and retry policy: no need to manage queues, workers, or infrastructure.
• The web service stays thin. All document intelligence calls run in isolated workflow tasks, keeping the HTTP layer free for uploads and SSE streaming.
• LlamaParse handles the hard part of document parsing (tables, complex layouts, scanned PDFs) across 130+ formats.
• LlamaCloud Classify and Extract layer document type detection and structured field extraction on top of raw parsing.
• LlamaCloud-managed pipelines make parsed documents instantly searchable with embeddings and reranking.

This guest post is kindly contributed by Descope, who help developers build secure, frictionless authentication and user journeys for applications.

While early adopters embraced running MCP servers locally via npx and uvx, enterprises quickly pushed back. Instead, they demanded remotely hosted servers that comply with the protocol's specification for security, scalability, and the credibility of MCP as a production-ready standard.

Unfortunately, many developers have run into two key challenges as a part of this shift: remotely hosting their MCP servers and implementing fully spec-compliant authorization. This template does the heavy lifting for you, allowing you to focus on the tools your server exposes instead of babysitting infrastructure.

How it works

We've released a secure FastMCP server that uses Render Blueprints for simple deployment. This MCP server enforces scope-based access control on every tool call. Agents perform the full MCP authentication process through a standard OAuth flow, receive a JWT scoped only to the permissions they need, and include that token on every request. If your agent doesn't have the right permissions to execute a tool, it's immediately rejected at runtime.

Here's what the core of a protected tool looks like:

First, your MCP server's tools declare the scopes required in order to use them. Descope manages the identity layer, handling token issuance, validation, and client registration. The descope-mcp SDK handles the primitive functions of scope validation. Finally, Render packages the full server logic into a hosted URL that's compatible with MCP clients like Cursor, Claude, and ChatGPT.

Ten minutes to a live server

The steps are simple. First, set up a Descope project and build locally. Using the instructions in the repo, configure your MCP server in Descope's Agentic Identity Hub, define your scopes, and grab the config URL.

Then, hit the Deploy to Render button. The included render.yaml handles the infrastructure: web service type, Python runtime, build commands, and more. Next, set your DESCOPE_CONFIG_URL environment variable. This is the Descope well-known URL obtained in the steps above. Deploy and watch Render build and start your MCP server on a live public URL.

The final step is to add your <project-name>.onrender.com URL to your MCP server configuration in Descope to ensure issued tokens only work for your server.

That's it! Descope handles all of the MCP auth complexity while Render takes care of everything else required for deployment.

One-stop-shop for MCP

I chose Render because infrastructure-as-code via render.yaml means the deployment is fully reproducible. Render Blueprints make it easy for anyone on your team to spin up an MCP server with the same configurations in no time.

Descope handles the specialized protocols required by MCP auth without extensive setup: OAuth 2.1, Protected Resource Metadata, Dynamic Client Registration, Client ID Metadata Documents, and much more. You can add fully spec-compliant MCP auth in less than 5 lines of Python.

Deploying on Render means there's a natural growth path from experimentation to production. Render handles scaling, custom domains, and infrastructure-as-code, while Descope manages scope issuance, enforcement, and access policies applicable to any attribute of the user or MCP client. It's everything you need to go from your first MCP server to the #1 app on the ChatGPT App Store.

Try it yourself

This template is your foundation for a production-ready, securely hosted MCP server.

Fork the repo, set up MCP auth in Descope, connect it to Render, and your secured MCP server will be live in minutes.

Today, we're launching new Pro and Scale plans with no seat fees, more self-serve compliance features, and fairer billing for bandwidth and custom domains.

These changes are designed to make Render's pricing more scalable for modern teams that are growing and shipping faster with AI. Under our new plans, 75% of paying Render customers will see their Render costs decrease or remain the same.

Here are the key updates:

• No seat fees. Our new Pro plan ($25/month) and Scale plan ($499/month) move to a flat subscription with unlimited team members included. Let your entire team ship at no extra cost.
• More compliance features, self-serve. SOC 2 and ISO reports are now available on Pro. Enterprise SSO, SCIM, advanced RBAC Roles, multi-workspace orgs, and HIPAA compliance are now included on Scale. Grow your team and infrastructure faster without signing a contract.
• Fairer bandwidth billing. Previously, we charged for bandwidth overages in 100GB increments. We're moving to per-GB billing at $0.15/GB, so you pay for exactly what you use. We are also reducing the bandwidth included in the Hobby and Pro plans. Previously, included bandwidth was subsidized by seat fees. Removing seat fees and billing for bandwidth more granularly makes our pricing fairer for all customers, regardless of team size.
• Custom domain pricing. Each workspace plan now includes a fixed number of custom domains for no extra charge. Additional domains will cost $0.25/domain/month. This change better aligns our pricing to our costs as more teams scale multi-tenant platforms on Render.
• Coming soon: new, high-memory compute plans. Customers on our new workspace plans will also have access to new high-memory compute plans for their services, improving efficiency for memory-intensive workloads.

We designed these changes based on feedback from thousands of customers to ensure Render's pricing is fair and transparent, and helps you build faster without arbitrary constraints.

Flat monthly workspace subscriptions and self-serve access to compliance and governance features also mean that teams can grow faster on more affordable plans, without per-seat costs or contracts. A small number of customers with very few seats, high bandwidth usage, or a large number of custom domains may see a price increase. If this applies to you, we will reach out to you via email with more information.

Our team is always happy to provide recommendations to optimize your spend and ensure you get the best value from Render. You can reach out to our team through your Render Dashboard. Official support is available for every user across every plan.

Read on for more details on these changes.

New plans. No seat fees. More self-service.

You shouldn't need to do the user seat shuffle to ship software.

Our workspace plans now use a flat monthly subscription model, so you can build faster with your entire team. Add your designer, your QA engineer, your contractor, or your clients: it won't change your bill.

We also consistently heard that teams need security reports and more granular platform governance sooner, so our new plans reduce the entry point for compliance features across the board. SOC 2 and ISO reports are now available on our Pro plan. Enterprise SSO, SCIM, advanced RBAC roles, and HIPAA compliance are included in the Scale plan.

Fair cost distribution for bandwidth and custom domains

With per-seat pricing, growing teams often paid more without receiving proportional value, especially if they did not use all the bundled bandwidth and unlimited custom domains included in the previous paid plans.

Our new approach better aligns our pricing with the value you receive from Render: a flat workspace subscription per plan, with a reasonable baseline for included bandwidth and custom domains. If you need more, you only pay for what you use. Additional bandwidth is now billed at $0.15/GB instead of in 100GB blocks, and additional custom domains are $0.25/month each.

Recap: Key changes to our plans

Below are all of the changes coming to our workspace plans. There are no changes to Render's existing compute pricing.

Hobby, $0/mo. Our free plan for personal projects.

• Unlimited projects. You can now create multiple projects in your Hobby workspace to group your services.
• 25-service maximum. Hobby workspaces are now capped at 25 total services.
• Custom domains: 2 domains still included. $0.25/month per additional domain.
• Bandwidth: 5GB of bandwidth included. Additional bandwidth billed at $0.15/GB.

Pro, $25/mo. Our new plan for lean teams building production software.

• No seat fees: Flat workspace subscription. Unlimited workspace members.
• Compliance: SOC 2 and ISO reports included.
• Custom domains: 15 custom domains included. $0.25/month per additional domain.
• Bandwidth: 25GB included. Additional bandwidth billed at $0.15/GB.
• Build minutes: 1000 minutes/month included. $5 per additional 1000 minutes.

Scale, $499/mo. Our new plan for teams with enterprise requirements.

• No seat fees: Flat workspace subscription. Unlimited workspace members.
• Compliance: Enterprise SSO, SCIM, and Advanced RBAC Roles, previously available only on Enterprise plans with a contract, are now included in Scale as self-serve features.
• Multiple workspaces: Organize teams and projects across multiple workspace under a single organization.
• HIPAA: We're lowering the cost of HIPAA compliance by removing the $250/month minimum fee. You now only pay 20% of compute, with no HIPAA minimum.
• Custom domains: 25 custom domains included. $0.25/month per additional domain.
• Bandwidth: 1000GB included. Additional bandwidth billed at $0.15/GB.
• Build minutes: 5000 minutes/month/workspace included. $5 per additional 1000 minutes.

Additionally, all new workspace plans will enable access to new, high-memory compute plans for memory-intensive services in the near future.

Opt into a new plan

We will begin rolling out plan changes to all workspaces in August, but you can also opt in today. We recommend reviewing your current usage and opting into the plan that best suits your needs. Most customers will reduce their bill by opting into a new plan.

Starting August 1st, 2026, workspaces remaining on legacy plans will convert to the following plans by default:

• Hobby plan customers will remain on the Hobby plan, with new plan changes in effect
• Professional plan customers will convert to Pro
• Organization plan customers will convert to Scale

If you have questions, concerns, or need help choosing a plan, please reach out to our Support team through the Render Dashboard.

Ship directly from Codex with the Render Plugin

Hazal Mestci

April 16, 2026

Although coding agents have transformed how developers write software, infrastructure work like deploying services and debugging configs has remained stubbornly manual. Today, that changes. We're introducing the Render Codex Plugin, which lets Codex deploy, debug, and monitor your apps on Render.

With the plugin, you can prompt Codex to:

• "Deploy this project to Render."
• "Debug this failed deployment."
• "Check the status of my services."

Codex executes these tasks step by step, checking configurations, retrieving logs, and guiding fixes.

Your gateway to the Render ecosystem

The plugin ships with skills: structured, step-by-step playbooks that teach Codex how to work with Render. Skills cover the full deployment lifecycle, from creating a new service to validating a render.yaml blueprint, reading deploy logs, diagnosing common failure modes, and checking service status. They're synced from maintained definitions and updated continuously as the platform evolves, so the agent's knowledge stays current as Render ships new features.

The plugin works with the Render CLI for tasks that interact with the Render API. Install it with brew install render, authenticate with render login, and verify your session with render whoami -o json before running any Codex tasks.

Install the Render plugin

To get started, open the in-app marketplace or type /plugins in the Codex CLI and search for Render. Once installed, make sure the Render CLI is authenticated, and you're ready to go.

We're excited to see what you ship.

Build durable, long-running AI workflows and background jobs with an SDK. Now in beta for TypeScript and Python.

Deploying background workloads for your agents and apps should be as simple as pushing the code.

Instead, running them reliably still means standing up your own queues, workers, state management, and retry infrastructure.

We're launching Render Workflows to help you build reliable, long-running processes like agent logic, data pipelines, and billing flows without making distributed systems your full-time job.

Define tasks and chained logic in your TypeScript or Python code using the Render SDK, and trigger them from anywhere. Render handles the infrastructure to make your workflows low-latency, stateful, and resilient.

Fully-managed execution

A Workflow service in Render is an all-in-one package of queuing, worker pools, state management, retry logic, and observability. You define processes as a collection of tasks in your code using the Render SDK, deploy your code as a Workflow service in Render, and Render handles execution whenever you trigger a task.

For you, that means:

Just write code. Use the Render SDK to turn any function into a durable task with its own retry behavior. Like regular functions, you can chain tasks to define multi-step logic and parallel execution.

Automatic infrastructure. When you trigger a task, Render spins it up in its own isolated container within milliseconds and automatically serializes and transports args to containers for chained tasks.

Parallel execution. Parallelize heavy workloads across hundreds of concurrent containers. Render automatically handles scheduling and provisioning for tasks that are invoked in parallel.

Cost scales to zero. You only pay for the compute your tasks run on, prorated to the second. If you aren't running any tasks, you aren't paying anything. You can also define the compute plan for each task independently to optimize your spend for lighter and heavier tasks.

Run, observe, and debug in one place. Your tasks run on a private network alongside your other Render services. You can see a unified view of metrics and logs for every task run in the Render dashboard. No glue code. No jumping between dashboards to debug a failed run.

Define workflow tasks

Your workflow is a collection of tasks. Tasks are just as flexible as regular functions, but each can have its own retry logic, timeout, and compute plan.

In TypeScript, you define tasks using the task() wrapper function. In Python, use the @app.task decorator:

import { task } from '@renderinc/sdk/workflows'

const generateCode = task({
  name: 'generateCode',
}, async function (plan: AppPlan, model: string) {
  // generate code based on AppPlan with selected model, parse response into files
})

from render_sdk import Workflows
app = Workflows()

@app.task  # Python SDK infers task name from function name
async def generate_code(plan: dict, model: str):
    # generate code based on AppPlan with selected model, parse response into files

To configure retry behavior, timeout, and compute for your task, add them directly to the task definition:

const generateCode = task({
  name: 'generateCode',
  retry: {
    maxRetries: 3, // retry up to 3 times
    waitDurationMs: 1000, // wait 1s before first retry
    backoffScaling: 1.5 // exponential backoff for subsequent retries
  },
  timeoutSeconds: 60, // configurable up to 24 hours
  plan: 'starter' // configurable up to 'Pro Ultra' (8 CPU / 32GB RAM)
}, async function (plan: AppPlan, model: string) {
  // generate code based on AppPlan with selected model, parse response into files
})

from render_sdk import Workflows, Retry
app = Workflows()

@app.task(  # Python SDK infers task name from function name
    retry=Retry(
        max_retries=3, # retry up to 3 times
        wait_duration_ms=1000, # wait 1s before first retry
        backoff_scaling=1.5 # exponential backoff for subsequent retries
    ),
    timeout_seconds=60, # configurable up to 24 hours
    plan="standard" # configurable up to 'Pro Ultra' (8 CPU / 32GB RAM)
)
async def generate_code(plan: dict, model: str):
    # generate code based on AppPlan with selected model, parse response into files

Workflows are most useful when you need to run complex processes made up of many sequential and parallel tasks. You can build that logic by chaining tasks just like you would normal functions.

For example, an agent that generates code for a web app may need a loop that chains multiple LLM calls and sandboxes to generate, validate, and display a preview to the user after a prompt:

const generationLoop = task({ name: 'generationLoop' },
  async function (prompt: string, userId: string, startingSnapshotId?: string) {
    // create a plan from the prompt (or modify existing plan if iterating)
    let plan = await planStructure(prompt, startingSnapshotId)
    let code = await generateCode(plan)
    let sandboxId = plan.sandboxId
    const errors: BuildError[] = []

    // build → check → revise until it works (max 3 attempts)
    while (errors.length < 3) {
      const build = await buildInSandbox(code, sandboxId)
      sandboxId = build.sandboxId
      if (build.success) {
        // deliver preview to user and save state in parallel
        await Promise.all([
          pushPreview(userId, build.previewUrl),
          saveSnapshot(sandboxId, code)
        ])
        return
      }
      // build failed: revise plan and fix code
      errors.push(build.errors)
      plan = await revisePlan(plan, errors)
      code = await fixCode(code, plan, build.errors)
    }
    // all attempts failed: explain what went wrong
    return diagnoseFailure(prompt, errors)
  }
)

const planStructure = task({ name: 'planStructure' }, ...) // prompt + optional snapshot → plan
const generateCode = task({ name: 'generateCode' }, ...) // plan → application code
const buildInSandbox = task({ name: 'buildInSandbox' }, ...) // install, compile, run
const revisePlan = task({ name: 'revisePlan' }, ...) // adjust plan from errors
const fixCode = task({ name: 'fixCode' }, ...) // targeted code edits
const pushPreview = task({ name: 'pushPreview' }, ...) // send preview URL to user
const saveSnapshot = task({ name: 'saveSnapshot' }, ...) // version current artifacts
const diagnoseFailure = task({ name: 'diagnoseFailure' }, ...) // explain failure to user

@app.task
async def generation_loop(prompt: str, user_id: str, starting_snapshot_id: str = None):
    # create a plan from the prompt (or modify existing plan if iterating)
    plan = await plan_structure(prompt, starting_snapshot_id)
    code = await generate_code(plan)
    sandbox_id = plan.sandbox_id
    errors = []

    # build → check → revise until it works (max 3 attempts)
    while len(errors) < 3:
        build = await build_in_sandbox(code, sandbox_id)
        sandbox_id = build.sandbox_id
        if build.success:
            # deliver preview to user and save state in parallel
            await asyncio.gather(
                push_preview(user_id, build.preview_url),
                save_snapshot(sandbox_id, code)
            )
            return
        # build failed: revise plan and fix code
        errors.append(build.errors)
        plan = await revise_plan(plan, errors)
        code = await fix_code(code, plan, build.errors)

    # all attempts failed: explain what went wrong
    return await diagnose_failure(prompt, errors)

@app.task
async def plan_structure(...): ... # prompt + optional snapshot → plan
@app.task
async def generate_code(...): ... # plan → application code

Trigger tasks

With your tasks defined, you can deploy your code as a Workflow service on Render and start triggering tasks.

Typically, you'll trigger tasks directly from your application code for other services on Render:

import { workflows } from '@renderinc/sdk'

const result = await workflows.generationLoop(prompt, userId)

from render_sdk import workflows

result = await workflows.generation_loop(prompt, user_id)

You can also trigger tasks from external services using the Render API or manually through the Render Dashboard.

Distributed execution, central observability

Because Render handles all of the infrastructure for your workflows from start to finish, it gives you a unified view of traces, metrics, and logs across every executed task without any additional setup.

You can analyze the reliability of individual tasks, monitor for opportunities to optimize compute, and debug failed runs through a single dashboard or CLI.

Observe workflows with a unified dashboard

Workflow examples and agent skills

To see some of the systems you can implement with Workflows, explore our curated examples in the Workflows Playground. You can also spin up an example workflow locally with the Render CLI:

Workflows are defined entirely in your code using an idiomatic SDK, so Claude Code, Cursor, Codex, and other agents can reason about them and build them for you.

To teach your agents how to build and debug workflows, install the workflows agent skill:

For the future of intelligent apps

Workflows are designed to let you build reliable, scalable, intelligent apps by just writing code.

AI agents need infrastructure shaped for long-running, stateful workloads. They depend on complex, multi-service agent loops, data pipelines, and other orchestration patterns that allow individual tasks to fail, retry, and parallelize gracefully.

With Workflows, you define that logic in your codebase and deploy it instantly, keeping you focused on building your product rather than infrastructure.

Over the course of beta, we'll be extending Workflows to expand the breadth of processes you can build:

• Vertically autoscale task compute to optimize performance and cost
• Kick off tasks via cron
• Pause and resume workflows
• Checkpoint state to recover from interruptions
• Additional language support

You can start building workflows today with the TypeScript and Python SDKs. Read the Workflows Docs to learn more.

How one developer built a multi-client AI roast engine, the "Sallyverse", on Render, ditching Vercel for background workers, Docker, and EU data residency.

With 4.5 million+ developers now on Render and more than 250,000 new developers joining every month, Render has evolved into one of the fastest-growing developer platforms in the world, and this funding will help us support our customers and expand Render’s offerings during a period of unprecedented hypergrowth.

My first job out of college was at Heroku. As it winds down, I'm reflecting on the movement it started and where we're taking that vision at Render.

Building features is fun. Finding the hardcoded port that caused your most recent deploy to fail is not. Integrate Render with Jules by Google Labs to let AI fix it for you.

Render customers' production workloads remained available during the us-east-1 incident. Read about the architectural choices that made that possible.

Infostealers can harvest credentials without your knowledge. We're keeping your Render account safe.

How we saved 7 TiB of memory across our Kubernetes clusters by disabling namespace listwatching in Vector, reducing daemonset overhead and API server load at scale.

A practical guide to building with OpenAI's Apps SDK. Learn what to expect from MCP tools, widget development, debugging 424 errors, and infrastructure choices.

We're scheduling maintenance for Render Key Value instances to patch this vulnerability and keep your infrastructure secure.

What if every deploy felt like a celebration? Here’s how I turned Render webhooks into a glowing light show on my desk.

Three hard-learned lessons from Render about using Informers in large clusters.

We benchmark AI coding agents (Cursor, Claude Code, Gemini CLI, OpenAI Codex) on production codebases in 2025, comparing setup speed, cost, context, and code quality.