November 2026 Summaries

Vercel Sandbox and Render Sandboxes both provide isolated Firecracker microVMs for running untrusted or agent-generated code, with active CPU and memory-based billing, OCI image support, Docker capabilities, snapshots, and JavaScript/Python SDKs. Vercel Sandbox is generally available and is positioned for applications already hosted on Vercel, offering 19 regions, public preview URLs, SSH-related networking options, credential brokering, high concurrency, and up to 64 GB of disk space, though sessions are capped at 24 hours on Pro plans and memory remains billed until a session ends. Render Sandboxes, currently in public beta and available only in Oregon, emphasizes long-running agent work through configurable or disabled timeouts, automatic idle suspension that stops compute billing, and runtime snapshots that preserve files, memory, and running processes for mid-task restoration. Render is particularly suited to teams whose backend services, databases, and workflows already run on its platform, while Vercel is preferable for Vercel-native workloads or requirements such as multiple regions, public URLs, and production-ready availability; Render’s current limitations include no private access to other Render services, public URLs, or SSH, although several of these features are planned.

Render’s OIDC integration lets services authenticate with providers such as AWS, GCP, OpenAI, and Anthropic without long-lived API keys, using cryptographically signed tokens configured largely through environment variables. Tokens include expiration, subject, issuer, and audience claims: they last 60 minutes to limit exposure, identify specific services and workspaces for access policies, isolate trust between Render workspaces even when provider policies are misconfigured, and prevent tokens intended for one provider from being reused with another. Because common provider SDKs generally expect OIDC tokens in files rather than fetching them dynamically, Render built an OIDC Daemon that runs outside each service container and writes frequently refreshed tokens into a shared, read-only in-memory filesystem mounted into the container. This approach supports custom images, limits the daemon’s filesystem access, avoids persisting credentials to disk, and automatically configures provider-specific SDK settings, aiming to make secure short-lived authentication as simple for users as selecting a provider.

Production hosting migrations should be treated as staged risk-management projects rather than quick moves, using four phases: creating a complete inventory, running the new stack alongside the old one, preparing and rehearsing rollback procedures, and performing database and DNS cutover. Successful preparation requires administrative access, a designated decision owner, an agreed maintenance window, and ownership for every service, scheduled job, secret, data store, domain, and certificate. Parallel operation allows teams to test production-like data migrations, validate background jobs and integrations, size infrastructure, and avoid duplicate writes or cron executions while the original platform remains available. Rollback plans must establish clear triggers, decision authority, DNS reversal steps, and reliable reconciliation of writes accepted after cutover, ideally through reverse replication or replayable audit logs. Database migration choices determine downtime, with dump-and-restore being simpler but requiring a longer write freeze, while logical replication supports near-zero downtime but requires schema preparation, sequence resets, monitoring, and platform-specific permissions. DNS records should have TTLs lowered well before cutover, custom domains and certificates should be configured in advance, and only one platform should accept database writes during the transition. After stability is confirmed, teams can raise TTLs, remove temporary replication, decommission the old environment after a defined safety period, and document lessons for future migrations.

Render’s official gha-runner example deploys an ephemeral self-hosted GitHub Actions runner as a Docker-based background worker, enabling CI jobs to access private Render services, databases, internal APIs, and custom toolchains through private networking. Each worker mints a fresh GitHub registration token using a securely stored classic PAT, registers for one job, runs it in a clean environment, deregisters, and repeats; Docker commands are supported through rootless Podman rather than privileged containers. Setup involves forking the example repository, configuring the target repository and compute plan in its Blueprint, deploying it through Render, adding the PAT as a dashboard-only secret, validating the runner and container support, and targeting it in workflows with self-hosted labels. Workers run continuously and incur charges even when idle, while each instance handles only one job at a time, so parallel workloads require additional instances and proportional cost. The guidance also emphasizes PAT rotation, avoiding public repositories and committed secrets, testing graceful shutdown behavior, rerunning Podman checks after plan changes, and using logs and label verification to diagnose registration, queueing, or container-build issues.

Render has launched Sandboxes in public beta, providing isolated Firecracker microVM-based Linux environments for AI agents to install dependencies, edit files, run code, and maintain state for tasks ranging from brief jobs to multi-day workflows. Available through TypeScript and Python SDKs, the Render CLI, and compatible with any agent framework or model, sandboxes can start in under a second, scale from individual instances to thousands, suspend automatically when idle, and use filesystem or runtime snapshots to preserve files, processes, and memory while reducing restart times. Security controls include configurable outbound network policies, early-access credential brokering that prevents API keys from entering sandbox environments, and scoped API keys with limited permissions. Billing is based on actively used CPU and allocated memory, with suspended sandboxes charged only for snapshot storage. Sandboxes operate within existing Render workspaces alongside services, databases, and workflows, enabling agents to test applications with Docker and Docker Compose, while planned additions include private networking, additional regions, SSH access, public URLs, resource bursting, and shared filesystems.