Skip to main content

​
Overview

Every create-spree-app project ships a ready Render Blueprint (render.yaml at the project root). It deploys the whole app in the single-node topology: one Docker service built straight from your repository plus a managed PostgreSQL — nothing else:
  • Web — one container running the Spree API and background jobs
  • PostgreSQL — the only backing service
Migrations run automatically on boot. Render builds the same image spree build --production builds locally.
Just evaluating Spree? Skip self-hosting entirely and use a hosted sandbox at spreecommerce.org.

​
Deploying

  1. Push your create-spree-app project to GitHub
  2. In the Render dashboard, click New → Blueprint and select your repository
  3. Render reads render.yaml and creates the services. Review and click Deploy Blueprint.
The database is seeded on first boot. Your store is ready in a few minutes — including any customizations, since the image builds from your repository.

​
After Deployment

​
Admin

No default admin account is created. Seeding prints a one-time setup link where you create the first admin account — print it again from the web service’s Shell tab with bin/rails spree:setup:token. The /jobs dashboard uses HTTP Basic auth: user jobs, with a password the Blueprint generates — read it in the Render dashboard under the web service’s Environment tab (MISSION_CONTROL_PASSWORD).

​
Environment Variables

Render sets DATABASE_URL, SECRET_KEY_BASE and the three Active Record encryption keys automatically from the Blueprint. Copy the encryption keys from the Environment tab into your secret manager as a backup — never change them once data is encrypted. For additional configuration (SMTP, file storage, Sentry, etc.), see Environment Variables. Generated URLs (images and attachments in API responses, email links) automatically use Render’s RENDER_EXTERNAL_HOSTNAME (<your-app-name>.onrender.com). When you attach a custom domain, set RAILS_HOST to it — it takes precedence.

​
Scaling Out

The Blueprint’s commented worker block switches to split mode: background jobs move into a dedicated service — same image, no rebuild. Uncomment it and set SOLID_QUEUE_IN_PUMA=false on the web service so it stops running jobs. For production workloads, we recommend: To enable auto-scaling, add this to the web service in your render.yaml:
High-traffic installs can additionally swap caching to a managed Redis/Valkey — the default needs no extra service.

​
Next Steps

Render provides ephemeral storage — uploaded files (product images, etc.) won’t persist across deploys. Set up cloud storage: Before going to production: Deploying a storefront? The Next.js storefront ships separately — typically to Vercel. See Storefront Deployment.