What shipped, newest first.

railyard apps:rm <app> deletes an app from the CLI, but only with --confirm <app-name> matching the app’s own name — the same typed-confirmation pattern the dashboard already uses for destructive actions, so a scripted deploy can’t accidentally delete the wrong app on a typo.

Ran a live verification pass across dozens of community app templates — Immich, Affine, MediaCMS, Supabase, Dify, Appwrite, LibreChat, Seafile, Rocket.Chat, PostHog, LogChimp, Castopod, Zulip, Airbyte, Langfuse and others — and fixed what a real deploy actually surfaced: missing environment variables, wrong default ports, and a handful of launch-key collisions where two templates shared the same identifier.

Same pass, three platform-level fixes that were never visible day to day but make a server more likely to quietly heal itself instead of needing a manual nudge: a server attaching storage on an unexpected device path, a routing watchdog that restarted too eagerly, and a DNS change whose dependents didn’t always pick it up. Browse the template catalog.

Anyone can now sign up without an invitation. New teams start on the Free plan (1 server, 3 apps) with 14 days of Pro, no card. Pro and Team are flat per-team prices with no usage billing; teams that joined before today keep Pro free. Pricing, Docs.

An independent security review led to tighter scoping of API tokens, stricter checks on outbound requests and hostnames, and no previews for pull requests from forks. We also fixed a number of smaller issues in app creation, deploy status updates and the public pages.

The proxy in front of every app now handles what you would otherwise configure in Nginx, from an app’s Settings → Networking:

• Redirects and rewrites, optionally limited to one host.
• Response headers and CORS, with preflight requests answered at the edge.
• Custom error and maintenance pages.
• Path routing to serve one app under a path of another.
• Your own TLS certificates, validated on upload and stored encrypted.
• Domain verification with a TXT record before Railyard routes a domain or issues a certificate, and wildcard domains on a single certificate.
• Rate limits and country blocking (beta).

See Edge rules and Domains.

• Canary deploys send a share of traffic to a new release, in one step or several (for example 5%, 25%, then 50%). The deploy page compares its error rate and latency with the current release, and Railyard can promote or roll back on its own.
• Deploy windows and scheduled deploys. Pushes outside an app’s window wait until it opens.
• Deploy notes on manual deploys and rollbacks, and rollbacks that restore the variables a release ran with.
• Apps across several servers, with health-checked load balancing and draining on removal.
• Automatic failover redeploys an app on another server, preferably in another region, when its server stops responding, promotes the database standby and updates DNS.
• Private networking across servers over an encrypted WireGuard mesh.

See Canary deploys and deploy windows and Scaling and failover.

• The CLI is a single binary for macOS and Linux, installed with Homebrew or a one-line script. railyard login signs in with a code confirmed in the dashboard, and railyard upgrade updates it in place.
• git push railyard main deploys that exact commit and streams the log back to your terminal, with no GitHub needed. Pushes are strict by default: a failed build rejects the push.
• railyard tunnel forwards a local port to an app or its database without opening a port, and railyard deploy --local builds with your own Docker.
• A Terraform provider for apps, variables and domains.
• Image apps follow their tag, redeploying when Docker Hub, GHCR, Quay or a private registry publishes a new digest.

See CLI and Terraform.

• Database servers hold data only: no proxy, no builds, and ports open only to the app servers that use them. Existing apps can move their data across with automatic fallback if the copy fails.
• Standbys that stream from the primary and can be promoted from either server’s page.
• Point-in-time recovery to any second in the last seven days, from WAL archived to your backup store. New database servers run Postgres 17.
• PgBouncer per server, with DATABASE_DIRECT_URL kept for migrations.
• Postgres major upgrades (beta) with a compatibility check, a backup first and seven days to roll back.
• Database forks for staging and previews, with an optional masking script that runs before anyone can connect.
• Consoles, export and import for every add-on, a file browser for object storage, and the option to keep object storage in your own AWS account.

See Database servers.

• Snapshots on DigitalOcean, Hetzner, Vultr and AWS, taken automatically before every resize.
• OS updates with pending and security counts, end-of-life warnings, one-click installs and optional nightly security updates.
• ActiveProtect bans IPs that probe for paths like /.env or /wp-login.php, and fail2ban stops SSH brute force. Servers switch to key-only SSH once a key is installed.
• Encrypted database storage in a LUKS volume, and encrypted disks on new AWS servers.
• A web application firewall (OWASP Core Rule Set) per app in detect or block mode, plus optional hardened isolation and read-only filesystems for containers.
• Secret detection warns when a repository commits credentials such as .env files or private keys.

See Server maintenance.

• The canvas is a live map of a project: its services, databases and the connections between them. Switch environments, fork a project, and see which service each teammate has open. Services reach each other at <app>.railyard.internal and reference each other’s variables with ${{service.VAR}}.
• Static sites and functions can be created from the canvas.
• Templates. Around 200 open-source apps are in a public catalog, and any project can be published as a template. Secrets are never published; they are asked for or generated at deploy time.
• Deploy to Railyard button for READMEs, which opens a prefilled setup on the visitor’s own server.
• TCP proxy for reaching a database from outside, turned on and off from its panel.

See The canvas and Deploy button.

• Sleep after the idle time you choose and wake on the next request. Staging and preview apps sleep after 30 idle minutes by default, awake hours keep an app up only during the times you set, and worker-only apps wake on schedule to drain their queues.
• Autoscaling of web replicas between a floor and a ceiling on p95 latency or CPU, with scheduled windows that add capacity before a known peak.
• Import from Heroku, Render, Fly.io and Railway with an API token: processes, variables, databases with their data, and domains. The Heroku, Render and Fly.io importers are in beta.
• Costs reads your real cloud bill, finds unused servers, disks and IPs, and alerts at 50%, 80% and 100% of a monthly budget. An optional hard cap puts non-production apps to sleep and blocks new servers.
• Public status pages with 90-day uptime.

See Costs and savings and Import from another platform.

Rails apps are detected on creation. Workers are found in the repository, assets build with Propshaft, importmap, jsbundling or cssbundling, Active Storage gets a persistent volume, and every database in database.yml is created, so Solid Queue, Solid Cache and Solid Cable work on Rails 8 without setup.

Laravel apps with laravel/octane run under Octane on FrankenPHP, and apps with laravel/reverb get a Reverb worker. Symfony and WordPress build without a Dockerfile too.

See Rails and Laravel.

• Single sign-on over OpenID Connect or SAML 2.0, with Google Workspace, Okta, Microsoft Entra, OneLogin and others. Domains are verified with a DNS record, new members join on first sign-in with the role you choose, and SSO can be required for everyone on your domain.
• SCIM 2.0 adds and removes members from your identity provider.
• Security score out of 100 from ten checks, including two-factor coverage, pending OS patches, open ports, expiring certificates and unverified backups. Each check links to its fix.
• Team SSH keys installed on every server the team runs, and removed within a minute when a key or member goes.
• MCP server for AI agents. Claude Code, Cursor and other MCP clients use the same API tokens as the CLI. Destructive actions become requests that an admin approves first.
• Account settings: change your email and password, export your data as JSON, or delete your account.

See Teams and SSO and MCP.

• Build servers. Give a server the builder role and it takes over compiling, so a heavy build never competes with live traffic on your app servers.
• Faster rebuilds from a shared build cache, and a memory cap so a large build fails cleanly instead of exhausting the server.
• Builds recover from common failures: outdated base images, older webpack builds, Node running out of memory, Python packaging edge cases and PHP version constraints. When a Dockerfile still fails, Railyard retries with Railpack using the versions pinned in your code.
• Multi-service repositories. A compose file or a repository with several Dockerfiles offers to create every service at once, with the datastores it needs.

• Metric alerts on p95 latency, 5xx rate, memory or CPU, checked every minute, with a follow-up when things recover.
• Access logs: every request through the proxy is logged with method, path, status, duration and client, and is searchable alongside your app’s logs.
• OpenTelemetry: give an app an OTLP endpoint and Railyard sets the standard OTEL_* variables and sends its own CPU, memory and request metrics to the same place.
• Job queue view (beta) for Sidekiq, Solid Queue, GoodJob, Resque and Delayed Job, with retry, discard and a backlog alert.
• Log retention per team, with search across any time range and plain-text download.

See Logs, metrics and alerts.

• A deploy is finished when users can reach it, not when the container starts. Railyard checks the app at its real HTTPS URL before moving traffic, and a redirect alone no longer passes as a healthy app.
• Crash loops pause. A process that keeps crashing for ten minutes is stopped instead of restarted forever, and the app page shows why it crashed. Restart starts it again.
• Live progress for long work. Creating a server, backups, restores, imports and resizes show their steps, recent output and time remaining, and keep running if you leave the page.

Repositories with no Dockerfile now build automatically with Cloud Native Buildpacks, using prebuilt runtime layers instead of compiling a language from source. Your repository is read the same way Heroku reads it, so an app moving over usually needs no changes.

A Procfile declares the process types and release command. Web and worker processes start from it, and the release: entry runs before the new version takes traffic.

See Build methods.

• Connect GitHub by installing the Railyard GitHub App once, then pick repositories from a list. Private repositories clone with short-lived tokens, pushes deploy, and commits get a status check.
• Connect GitLab, on gitlab.com or self-managed, with an access token under Team → Git providers.
• Preview environments for every pull request and merge request, removed when it closes. Staging environments can be promoted to production.
• Every failed deploy explains itself: the likely cause, the fix, and the log line that shows it, on the deploy page, the dashboard and the canvas.

See Connect GitHub and Environments and previews.

• Teams with owner, admin, developer and viewer roles, and members that can be limited to specific apps.
• Two-factor sign-in with any authenticator app, plus backup codes.
• A REST API with team-scoped tokens, and a command-line client built on it.
• Notifications for deploys, offline servers and crash loops, sent to Slack, a webhook or email.
• Deploy approvals: production deploys can wait for an admin to approve them.
• Activity log of every deploy, configuration change and server action.

• Create a server on DigitalOcean, Hetzner, Vultr, AWS or OVHcloud from the dashboard with your own API token, or attach any Linux server over SSH. Railyard finishes the setup, configures the firewall and keeps it updated.
• Every app gets a hostname and a TLS certificate as soon as it deploys. Add custom domains, served directly or redirected to the primary, with certificate status on the Domains tab.
• Scheduled jobs with run history and Run now.
• Server metrics with CPU, memory and disk charts, and alerts when a disk fills up or usage stays high.
• Maintenance mode per app.

See Add a server.

Add a datastore to an app and Railyard runs it on the same server, creates credentials for that app alone and sets the connection variables on the next deploy.

• Postgres (with pgvector), MySQL, Redis, MongoDB, Elasticsearch, Memcached, RabbitMQ, InfluxDB and S3-compatible object storage.
• Backups on a schedule with a retention you choose, one-click restore, and a verifier that restores each backup into a scratch database to prove it works.
• Persistent volumes for apps that write to disk, with their own backups.

See Databases and backups.

Railyard deploys a Git repository to a server you own: it clones the code, builds it and streams the build log to your browser as it runs.

• Zero-downtime releases. The new version starts next to the old one and only takes traffic once it passes a readiness check. A failed check leaves the old version serving.
• Web and worker processes, each with its own command and replica count, plus a release command that runs before traffic moves.
• Environment variables, encrypted at rest and editable one at a time or pasted as a .env block.
• Rollback to any earlier release in one click.
• Private sources: token-authenticated clones, submodules, build arguments, build secrets, and prebuilt images from a private registry.