How Rivarc would deploy Medusa v2 without code changes: 4 quick questions

[its-blue]

Hi Medusa team,

I'm Blue, CEO of Bluda. When I set up our online shop on open-source tooling, it took me three days of configuration, which is what led me to start Rivarc: an open-source project (planned NLnet grant application) that deploys existing self-hosted software and lets users wire it to databases, caches, storage and other apps through a graph. Each connection gets its own scoped credentials, and removing it revokes them.

Here's how Rivarc would deploy Medusa v2, in plain terms:

• Run the same backend image twice, with MEDUSA_WORKER_MODE=server (API and admin) and MEDUSA_WORKER_MODE=worker.
• Create a dedicated Postgres role that owns only the Medusa database, pass it via DATABASE_URL, and run medusa db:migrate as a one-off step on install and upgrade.
• Pass REDIS_URL to both server and worker, and generate JWT_SECRET and COOKIE_SECRET per deployment.
• Use the S3 file provider when the backend is connected to an S3 storage node, local files otherwise.
• When a Next.js storefront is connected to the backend: set the backend URL in the storefront, add the storefront's origin to STORE_CORS and AUTH_CORS, create a publishable API key through the Admin API, and inject it into the storefront. Removing the connection revokes that key.

A few questions, even short answers would help a lot:

1. Medusa is a project you scaffold rather than a fixed app. Is a single "canonical" medusa-config that reads all infrastructure (database, Redis modules, file provider) from environment variables realistic, or do production setups almost always need code-level config changes?
2. Is a Postgres role that owns only its database enough for migrations and normal operation?
3. Is creating and revoking publishable keys through the Admin API (with a secret API key) the intended way for an external tool to connect a storefront?
4. Is there anything in this description that's wrong or likely to cause problems in production?

I'm happy to share the full proposal draft. Replies here or by email at rivarc@bluda.tech both work for me.

Thanks,
Blue
CEO, Bluda

[DYNOSuprovo]

Hi Blue,

Your proposed architectural model for Rivarc mapping Medusa v2 to a declarative infrastructure graph is solid and closely aligns with Medusa v2's modular architecture.

Here are direct answers to your 4 questions based on Medusa v2 internals:

---

1. Is a single "canonical" medusa-config via environment variables realistic?

Yes, absolutely.
In Medusa v2, modules are configured declaratively in medusa-config.js / medusa-config.ts. A canonical configuration can read entirely from environment variables:

• Database: database: { url: process.env.DATABASE_URL }
• Redis (Event Bus & Workflows): In Medusa v2, Redis is wired into @medusajs/medusa/event-bus-redis and the workflow engine (@medusajs/medusa/workflow-engine-redis). You can conditionally load Redis modules if process.env.REDIS_URL is set, falling back to local defaults for dev.
• File Service: Configured under modules: [{ resolve: "@medusajs/medusa/file-s3", options: { ... } }]. If S3_BUCKET is present, enable S3; otherwise, fallback to @medusajs/medusa/file-local.

Because Medusa v2 configuration is standard JavaScript, you can export a canonical config file that evaluates environment flags without needing custom code changes per deployment.

---

2. Is a dedicated Postgres role that owns only its database enough for migrations?

Yes, with one caveat regarding PostgreSQL extensions.

• A dedicated role with OWNER privileges on the target database has full permission to run DDL (creating tables, alter schemas, indexes) for all Medusa v2 migrations.
• The caveat: Medusa v2 migrations require standard PostgreSQL extensions (specifically pg_trgm and uuid-ossp).
  • If your database provisioning step creates the extensions ahead of time (e.g. CREATE EXTENSION IF NOT EXISTS "pg_trgm"; run as a superuser/admin role during database creation), then the non-superuser application role can run all Medusa migrations without issue.

---

3. Is managing publishable keys via the Admin API the intended storefront connection mechanism?

Yes, this is the exact intended pattern in Medusa v2.

• Medusa v2 separates authentication into Secret API Keys (used by backend services/admin integrations via x-medusa-access-token) and Publishable API Keys (used by storefronts in the browser via x-publishable-api-key).
• Your automated provisioning flow:
  1. Bootstraps a temporary or scoped admin secret token.
  2. Calls POST /admin/api-keys with { title: "Rivarc Storefront", type: "publishable" }.
  3. Associates the publishable key with sales channels via POST /admin/api-keys/{id}/sales-channels.
  4. Injects NEXT_PUBLIC_MEDUSA_PUBLISHABLE_KEY into the Next.js storefront environment.
  5. On teardown, calling POST /admin/api-keys/{id}/revoke immediately cuts off storefront access without restarting containers.

---

4. Any potential gotchas or edge cases in your description?

A few key considerations to ensure production stability:

1. Migration Race Conditions:
   • Since both server and worker instances run the same container image, ensure medusa db:migrate runs as an init-container or pre-start hook that completes before server or worker processes are booted, preventing schema locks or failed initial queries.
2. Redis is Mandatory for Multi-Instance / Workers:
   • In Medusa v2, while a single local instance can run with in-memory event buses, running split MEDUSA_WORKER_MODE=server and MEDUSA_WORKER_MODE=worker requires Redis for distributed event propagation and workflow orchestration. Ensure Rivarc enforces Redis when worker mode is split.
3. Admin User Seeding:
   • Running migrations creates the schema, but you also need an initial admin user to generate the first API key. Ensure your automated install runs medusa user -e <email> -p <password> (or uses a seed script) before the admin API is called.

If this architectural breakdown clarifies your Rivarc Medusa deployment blueprint, feel free to mark this as the accepted answer!