• Docs
  • Changelog
Sign in
Get started
    • Home
    • Your first deploy
    • Free instances
    • Platform features by plan
    • Use with coding agents
    • FAQ
    • Templates
      • Migrate from…
        • Heroku
        • Railway
    • Compute plans
    • SandboxesBeta
      • Service types
        • Which to use?
        • Static sites
        • Web services
        • Private services
        • Background workers
        • Cron jobs
        • Workflows
        • Multi-service architectures
      • Data storage
        • Render Postgres
        • Render Key Value (Redis®-compatible)
        • Persistent disks
    • How deploys work
    • Supported languages
    • Git providers (GitHub, etc.)
    • Build pipeline
    • Deploy hooks
    • Monorepo support
    • Troubleshooting deploys
      • Previewing changes
        • Single-service previews
        • Preview environments (multi-service)
      • Docker deploys
        • Overview
        • Deploy a registered image
        • Using secrets
      • Runtime
        • Native runtimes
        • Environment variables & secrets
        • Default environment variables
    • Intro to sandboxes
    • Limits
      • How to…
        • Create & configure sandboxes
        • Execute commands
        • Manage files
        • Manage snapshots
      • Use with…
        • Claude Managed Agents
        • Cursor Cloud Agents
        • OpenAI Agents API
      • SDK/CLI reference
        • TypeScript SDK
        • Python SDK
        • CLI commands
    • Intro to workflows
    • Tutorial
    • Limits & pricing
      • How to…
        • Define tasks
        • Define flowsNew
        • Trigger runs
        • Develop locally
      • SDK reference
        • TypeScript SDK
        • Python SDK
      • Example workflows
        • TypeScript examples
        • Python examples
    • Overview
    • Create & connect
    • Database credentials
    • Extensions
    • Version upgrades
    • Logical replication
    • Legacy instance types
      • Database recovery
        • Recovery & backups
        • High availability
      • Database performance
        • Read replicas
        • Connection pooling
        • Admin apps
        • Repacking tables
        • Troubleshooting performance
    • Regions
    • Inbound IP rules
    • Edge caching
    • WebSockets
    • TLS certificates
      • Custom domains
        • Overview
        • Cloudflare
        • Namecheap
        • Other DNS providers
      • Internal traffic
        • Private network
        • Private links
      • Outbound traffic
        • Default IP ranges
        • Dedicated IP addresses
        • Outbound bandwidth
        • Handling network changes
      • Static site config
        • Custom response headers
        • Redirects & rewrites
    • The Render Dashboard
    • SSH / Shell access
    • Projects & environments
      • Service actions
        • Scaling
        • Rollbacks
        • Maintenance mode
        • One-off jobs
      • Infrastructure as code
        • Blueprints overview
        • render.yaml reference
        • Terraform provider
    • In-dashboard metrics
    • Health checks
    • Uptime best practices
      • Logging
        • In-dashboard logs
        • Log streams (syslog/HTTPS)
      • OpenTelemetry (OTel) metrics
        • Provider setup
        • Metrics reference
      • Notifications
        • Webhooks
        • Email / Slack
    • MCP Server
      • Render CLI
        • Overview
        • Command reference
      • REST API
        • Overview
        • API reference
      • Third-party connections
        • OIDC support
        • Datadog
    • Workspaces, members, & roles
    • Login settings
    • Audit logs
      • Organizations
        • Overview
        • SAML SSO
    • DDoS protection
    • Platform maintenance
      • Compliance
        • Overview
        • HIPAA (US health data)
        • HIPAA best practices
        • Shared responsibility model
        • Pentest policy
    • Heroku vs Render
    • Vercel vs Render

Local Dev with Render Workflows

Run tasks locally for faster development and testing.

You can run workflow tasks on your local machine to iterate on them quickly. The Render CLI supports spinning up a local task server that simulates the entire run execution lifecycle. You can trigger task runs from your application code, or from the CLI itself.

As you iterate on your task definitions, the local task server picks up changes automatically. It also retains in-memory logs and results for each run (these are lost on server shutdown).

Prerequisites

Your development machine must have:

  • The Render CLI version 2.35.0 or later

    Installation instructions

    Use any of the following methods to install the Render CLI or upgrade to the latest version:

    Homebrew installation

    Run the following commands:

    WinGet installation

    Run the following command:

    Installing with curl

    Run the following command:

    Direct download
    1. Open the CLI's GitHub releases page.
    2. Download the executable that corresponds to your system's architecture.

    If you use an architecture besides those provided, you can build from source instead.

    Building from source

    We recommend building from source only if no other installation method works for your system.

    1. Install the Go programming language if you haven't already.

    2. Clone and build the CLI project with the following commands:

    After installation completes, open a new terminal tab and run render with no arguments to confirm.

  • A workflow project repo that defines and registers tasks

    • Create your first workflow

Limitations

  • The local task server does not yet support flows (tasks only).
  • Workflows that build from a Dockerfile do not currently support the local task server.
    • See all current Docker-specific limitations.

Starting the task server

From your workflow project repo, run the following command:

Replace <WORKFLOW_START_COMMAND> with the command to start your workflow service, such as:

Command not found?
  • Make sure you've installed the Render CLI.
  • Run render --version to confirm you're using version 2.35.0 or later.

Your local task server spins up and starts listening on port 8120.

You can specify a different port with the --port option:

Triggering local task runs

In application code

This section assumes you have an existing app that triggers task runs.

If you don't, first get set up with Triggering Runs.

You can configure your locally running apps to point to your local task server when triggering task runs. How you do this depends on whether your app uses the Render SDK or the Render API:

If your app uses the Render SDK (TypeScript or Python) to trigger task runs, set the following environment variable(s) to run tasks against your local task server:

If your app uses the Render API directly to run tasks, swap out the base URL you use for task-related endpoints with your local task server's URL.

Here's a Node.js example:

In this example, you would set the RENDER_TASKS_URL environment variable to your local task server URL (e.g., http://localhost:8120) to use it for development.

Note that the local task server only simulates task-related endpoints. Other Render API endpoints are not supported.

In the Render CLI

  1. With your local task server running, run the following command:

    Don't forget the --local flag! Otherwise, the CLI lists tasks from your deployed workflow services.

    The CLI opens an interactive menu of your locally registered tasks:

    Listing tasks in the Render CLI

  2. Select a task and press Enter, then select the run command.

    The CLI prompts you to provide the task's input arguments as a JSON array:

    Providing input arguments for a task run in the Render CLI

    If your task takes zero arguments, provide an empty list, [].

  3. Provide your desired arguments and press Enter. The CLI kicks off your task with a request to your local task server and begins tailing its logs.

    You can remain in this view to view live logs from your task run.

  4. Press Esc to navigate back up to the list of commands for your task. This time select the runs command.

    The CLI opens an interactive menu of the task's local runs:

    Viewing task runs in the Render CLI

  5. Select a run and press Enter, then select the results command.

    The CLI opens a view of the run's results:

    Viewing task run details in the Render CLI

In non-interactive environments, provide any of -o text, -o json, or -o yaml to Render CLI commands to disable menu navigation and receive output in the desired format.

The example commands below use -o text:

  1. With your local task server running, run the following command to list your locally registered tasks:

    Don't forget the --local flag for all of these commands! Otherwise, the CLI runs them against your deployed workflow services.

  2. Start a run for that task, passing input as a JSON array:

  3. List runs for the task:

  4. Fetch details and results for a run by its ID:

Local-only considerations

  • Logs and results for local task runs are stored in memory by the local task server.
    • This data is lost when the server shuts down.
    • This data is retained indefinitely as long as the server is running. This can lead to high memory usage over time.
    • If you trigger a high volume of local task runs, we recommend periodically restarting your local task server to free up memory.
  • Identifiers for local tasks and runs are randomly generated IDs.
    • The identifier for a given task differs each time you run the local task server.
    • Local identifiers do not correspond to any values in your deployed workflow services.
Local Dev with Render Workflows
  • Prerequisites
    • Limitations
  • Starting the task server
  • Triggering local task runs
    • In application code
    • In the Render CLI
  • Local-only considerations
All Systems Operational
© Render Inc. All rights reserved.