Can I deploy these templates for free?

The MCP server template is a single web service that can run on Render's Free instance type, though a Free web service spins down after 15 minutes without traffic and takes about a minute to wake on the next request. The others need at least one paid resource. Opencode requires a persistent disk, which isn't available on Free instances. Flue with PostgreSQL pairs a web service with a managed Postgres database. The Voice Agent and AEO analytics templates run tasks on paid Render Workflow instances. Managed Postgres is free for the first 30 days, after which you upgrade or recreate it.

Do I need to use TypeScript with these templates?

The Voice Agent, MCP server, Opencode, and Flue templates are TypeScript-first. AEO analytics pairs a Next.js/TypeScript dashboard with Python for LLM processing. Render's Node build/start commands are just shell commands with no built-in TypeScript handling — add a tsconfig.json and a build script (e.g. tsc) to compile TypeScript before Render runs it.

Do these templates need database migrations?

Not to get started. Flue's Postgres session store creates its flue_sessions table on first use, so the agents persist conversation history with no separate migration step. AEO analytics manages its schema with Drizzle ORM, and any Node service can run its own migration tool on deploy through the build command.

Do Render Postgres connection strings need SSL configuration?

When your service connects over Render's private network using the internal connection string, no extra SSL setup is needed. For external connections, use the external connection string with sslmode=require rather than disabling certificate verification in your client.

Can a single render.yaml deploy multiple services at once?

Yes. One Blueprint can declare web services, background workers, cron jobs, Postgres databases, Key Value instances, and persistent disks side by side, and Render provisions them together on first deploy—the AEO analytics template stands up a web service, a Postgres database, and a cron job together. Render Workflows are the exception: they're deployed as their own Workflow service and aren't declared in render.yaml yet, so templates like the Voice Agent link the workflow separately.

Do Render Workflows run on a schedule?

Render Workflows have no built-in scheduler. To run a task on a schedule, use a Render cron job that triggers the task through the Render API, as the AEO analytics template does for its daily LLM poll. Individual runs can last up to 24 hours and retry with exponential backoff. See the Workflows docs for details.

Deployment

5 JavaScript/TypeScript apps to deploy on Render

July 02, 2026

Five JavaScript/TypeScript apps you can deploy on Render today, each backed by a one-click template. They lean into AI—voice agents, stateful AI agents, an MCP server, a coding agent—and the throughline is how each one is wired: every template maps a working app onto Render's service types and declares that wiring as a Blueprint you can read, deploy, and adapt.

JavaScript and TypeScript run the full stack of modern web and AI apps, and the shapes those apps take map directly to Render's core service types: real-time voice agents, MCP tool servers, stateful agents backed by managed Postgres, browser-based coding agents, and analytics dashboards backed by scheduled LLM polls. A frontend becomes a static site, a backend becomes a web service, a long-running process becomes a Render Workflow or background worker, and state lives in managed Postgres or Key Value. Render's Node runtime builds, runs, and scales each one straight from a connected Git repository with no DevOps configuration, and every example below has a corresponding starter template on render.com/templates.

A JavaScript or TypeScript app stitches together a build pipeline, a runtime process, environment variables, and often a database or queue. Wiring that by hand is easy to get subtly wrong: a missing port binding, the wrong package manager, or a DATABASE_URL pointed at the wrong instance. A Render template encodes a working configuration as a reusable Infrastructure as Code Blueprint, so every app in this guide deploys through the same one-click pattern:

A template is an open-source Git repository containing a render.yaml Blueprint that declares every resource the app needs.
Clicking Deploy to Render reads the Blueprint and provisions exactly what it declares, with no manual setup.
Services provide compute and routing, including web and static services, background workers, and cron jobs, each built and run by Render's Node runtime straight from a connected Git repository.
Managed resources hold state, including Postgres databases and Key Value instances that survive redeploys.
Environment variables configure and secure the app. They are injected at runtime, so credentials never live in source.

A minimal Blueprint pulls these pieces together:

yaml

services:
  - type: web
    name: js-app
    runtime: node
    buildCommand: npm install && npm run build
    startCommand: npm start
databases:
  - name: js-app-db
    plan: free

Once you understand this pattern, you can read any of the apps below and know what a single click stands up. For the full schema, see the Blueprint specification.

This template deploys an insurance claim application where a caller files a claim by talking to a browser-based AI agent. A React/TypeScript frontend runs as a static site and a backend API as a web service, a LiveKit voice agent (OpenAI GPT-4o, Whisper, and TTS) runs as a background worker, and Render Workflows orchestrate the claim-processing steps—policy verification, damage analysis, fraud checks, cost estimates, and repair-shop lookup—running the independent checks in parallel with automatic retries. Progress streams back to the UI as each subtask finishes.

The signature move is fanning the independent checks out in parallel, shown here with the TypeScript Workflows SDK:

typescript

// tasks.ts — Render Workflows fan-out for parallel claim processing
import { task } from "@renderinc/sdk/workflows";

const verifyPolicy = task({ name: "verifyPolicy" }, (claim: object) => ({ covered: true }));
const analyzeDamage = task({ name: "analyzeDamage" }, (claim: object) => ({ severity: "moderate" }));
const checkFraud = task({ name: "checkFraud" }, (claim: object) => ({ risk: 0.02 }));

task({ name: "processClaim" }, async function processClaim(claim: object) {
  const [policy, damage, fraud] = await Promise.all([
    verifyPolicy(claim),
    analyzeDamage(claim),
    checkFraud(claim),
  ]);
  return { policy, damage, fraud };
});

Render Workflows are deployed as their own Workflow service and aren't declared in render.yaml yet, so the Blueprint provisions the web and worker services while the workflow is linked separately in the Dashboard.

Flue (flueframework.com) is a TypeScript framework for webhook-triggered AI agents with structured outputs and SSE streaming. This template ships two agents—a translation agent that returns Valibot-typed JSON with a confidence level, and a conversational assistant that keeps multi-turn memory across requests. It runs as a single web service: a Hono server that flue build --target node bundles into a self-contained dist/server.mjs, exposing each agent as POST /agents/<name>/<id>. A managed Postgres database holds state, and a Postgres-backed session store persists conversation history to a flue_sessions table so sessions outlive restarts and deploys. You add an Anthropic API key after the first deploy.

The signature move is that persistence layer, and the Blueprint keeps it to two resources:

yaml

# render.yaml — a Flue web service wired to managed Postgres
databases:
  - name: flue-db
    plan: basic-256mb

services:
  - type: web
    name: flue-agents
    runtime: node
    plan: starter
    buildCommand: npm ci && npx flue build --target node
    startCommand: node dist/server.mjs
    healthCheckPath: /health
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: flue-db
          property: connectionString
      - key: ANTHROPIC_API_KEY
        sync: false

fromDatabase injects the Postgres connection string at deploy time, so the agents find their database without a hardcoded URL. The session store creates the flue_sessions table on first use, so there's no separate migration step.

The AEO analytics template deploys a dashboard that tracks how large language models mention and rank your brand—answer engine optimization. A Next.js dashboard runs as a web service, backed by a managed Postgres database whose schema is managed with Drizzle ORM. A Render Workflow polls OpenAI, Anthropic, and Google models with your configured prompts, extracting brand mentions, sentiment, competitive rankings, and URLs. Because Workflows have no built-in scheduler, a cron job triggers the daily run by posting to the Render API:

typescript

// cron.mjs — a Render cron job kicks off the daily LLM poll
const taskPath = `${process.env.RENDER_WORKFLOW_SLUG}/daily-job`;

const res = await fetch("https://api.render.com/v1/task-runs", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.RENDER_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({ task: taskPath, input: [] }),
});

console.log("Daily poll triggered:", res.status);

The task identifier follows the {workflow-slug}/{task-name} format shown on the task's page in the Dashboard.

The MCP server template is a production-ready starting point for a Model Context Protocol server that exposes your own tools to AI clients like Claude, Cursor, and Codex. It runs as a single web service built on the official MCP SDK, with Express middleware handling HTTP transport, bearer-token auth via an auto-generated MCP_API_TOKEN, Zod-validated parameters, and a /health endpoint. It ships an AGENTS.md so AI coding assistants can scaffold new tools that follow the project's conventions.

typescript

// server.ts — registering a tool with Zod-validated parameters
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { z } from "zod";

const server = new McpServer({ name: "my-mcp-server", version: "1.0.0" });

server.registerTool(
  "get_weather",
  {
    description: "Get the current weather for a city",
    inputSchema: { city: z.string() },
  },
  async ({ city }) => ({
    content: [{ type: "text", text: `Weather in ${city}: sunny` }],
  }),
);

Bind the transport to process.env.PORT on host 0.0.0.0 so Render can route traffic to the service.

The Opencode template runs opencode, an open-source AI coding agent, as a persistent cloud service you reach from a browser UI or remotely from your terminal with opencode attach. It's a single web service backed by a 1 GB persistent disk that preserves SQLite session state across deploys. It uses your Anthropic or OpenRouter API key for model access, can auto-clone a (private) GitHub repo on first boot, and ships with the Render MCP server pre-installed so the agent can validate Blueprints and manage deploys.

yaml

# render.yaml — a web service with a persistent disk for session state
services:
  - type: web
    name: opencode
    runtime: node
    plan: starter
    disk:
      name: project-data
      mountPath: /root/project-data
      sizeGB: 1
    envVars:
      - key: ANTHROPIC_API_KEY
        sync: false
      - key: OPENROUTER_API_KEY
        sync: false

sync: false marks a secret you set in the Dashboard rather than committing to source. The persistent disk keeps files—in this case, the SQLite session database—across deploys and restarts. A web service without a disk gets an ephemeral filesystem that resets on every deploy.

5 JavaScript/TypeScript apps to deploy on Render

Why JavaScript and Render belong together

The Render template mental model

Voice agent: real-time claim processing with parallel Workflows

Flue with PostgreSQL: stateful AI agents that survive restarts

AEO analytics: track how LLMs rank your brand

MCP server (TypeScript): expose your own tools to AI clients

Opencode: a browser-based AI coding agent

Frequently asked questions