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

Default credentials are created during seeding. Change them immediately after first login. 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 and SECRET_KEY_BASE automatically from the Blueprint. 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.