Preview environments for Rails + React
Every pull request boots a real Rails + React environment — the right Ruby version, gems compiled, db:prepare migrated and seeded, Sidekiq draining jobs and the React bundle built — on a managed VPS behind its own HTTPS URL. Live in minutes, gone clean when the branch merges.
- ✓ Pinned Ruby + native gems
- ✓ Sidekiq + Redis
- ✓ Migrated & seeded Postgres
A Rails + React PR has a lot of moving parts
Reproducing one branch means matching the Ruby version, recompiling native gems, running pending migrations and seeds, getting Sidekiq draining jobs against Redis, and rebuilding the JavaScript bundle. Do that by hand for every PR and review slows to a crawl; share one staging box and whoever deploys last wins.
Ruby + gems never quite match
A branch bumps .ruby-version or adds a gem with C extensions. It builds on one laptop, fails to compile on the next, and the reviewer gives up.
Migrations on a shared database
Two open PRs, one staging Postgres. One branch’s db:migrate reshapes a table the other depends on, and suddenly nobody trusts what they’re testing.
Stale bundles & idle Sidekiq
The reviewer forgets to rebuild the React bundle, or Sidekiq isn’t running, so background jobs never fire and the feature looks broken when it isn’t.
What every Rails + React preview includes
Each branch boots a complete stack on its own VPS — the Ruby app, its frontend build, the worker and every backing service, wired together and served on one origin.
bundle install with native gems compiled into the image.bundle exec puma with RAILS_ENV set per environment.npm ci && npm run build, digested and shipped.db:prepare + db:seed on boot.RAILS_MASTER_KEY injected, a real HTTPS certificate.Exactly the steps you’d run by hand
You declare the bundle, build and migrate commands once. We run them in a clean container on every push — no bespoke CI YAML, no SSH, no manual rails server.
# on every push to the branch bundle install # pinned Ruby + native gems bin/rails db:prepare # create + migrate isolated DB bin/rails db:seed # realistic data npm ci && npm run build # or: bin/rails assets:precompile bundle exec puma & bundle exec sidekiq ✓ ready https://acme-billing-redesign.admn.cloud
From branch to shareable URL in three steps
- 01
Connect the repo
Point ADMN at your Rails + React repository and declare your bundle, build and migrate commands plus a database template — once.
- 02
Pick a branch
Choose any branch or PR. We provision a dedicated VPS, install gems, build the React bundle, prepare and seed the database, and start Puma and Sidekiq.
- 03
Share the URL
A live HTTPS environment for QA, design review or a client demo. Renew the lease to keep it, or let it expire and tear down clean.
Rails + React preview environments, answered
Does it run db:migrate and seed the database?
Yes. Each environment gets its own isolated Postgres (MySQL or Mongo if your project uses them). On first boot we run `bin/rails db:prepare` — which creates the database and runs any pending migrations — then `bin/rails db:seed`, so the preview opens on realistic data rather than an empty schema. The database is dropped with the environment, so one branch’s migrations can never corrupt another’s.
How do Sidekiq and Active Job work?
A Redis instance is provisioned per environment, and the same image starts a `bundle exec sidekiq` worker process alongside Puma. Mailers, Active Storage analysis, and any `perform_later` jobs drain exactly like production. If you use the Async or Solid Queue adapter instead, declare that process line and we run it the same way — plus a scheduler for recurring jobs.
My React frontend is bundled with jsbundling-rails — and someone uses importmap. Both?
Both. If React is bundled through jsbundling-rails with esbuild or Vite, we run `npm ci && npm run build` (or `bin/rails assets:precompile`) so the digested bundle lands in `public/assets` and Propshaft/Sprockets serves it. If you lean on importmap-rails instead, there’s nothing to bundle and the precompile step is enough. Either way the compiled assets ship with the environment — never a dev server.
What if React is a separate SPA, not served by Rails?
That works too. Define Rails as the API service and the React app as its own service in the same environment; we build the SPA, set its API base URL to the Rails service’s generated HTTPS URL, and serve both behind one origin so there are no CORS surprises. You get a single shareable link that loads the React app talking to a live Rails API.
How are Rails credentials and RAILS_MASTER_KEY provided?
You store `RAILS_MASTER_KEY` (or your `config/master.key`) as a project secret. It’s injected into each environment so Rails can decrypt `config/credentials.yml.enc` at boot — your encrypted credentials file stays in the repo, the key never does. RAILS_ENV, the per-environment `DATABASE_URL` and `REDIS_URL`, and any other secrets are rendered into the environment automatically.
Does it handle Active Storage uploads?
Yes. Active Storage runs against the local disk service inside each environment, so uploads, variants and direct-upload flows work end to end without touching a shared bucket. Because storage is scoped to the environment, files created while testing a branch vanish cleanly when the environment is torn down.
Ship your next Rails + React PR with a live URL
Connect GitHub and get a full-stack preview environment for every branch — gems compiled, database migrated and seeded, Sidekiq running, then destroyed without a trace.