When Saleor Cloud fits and when self-hosted Saleor fits
Choose Saleor Cloud when your team has no platform engineers, your GMV sits inside the published plan ranges, and vendor hosting is acceptable to your data protection and security owners. Choose self-hosted Saleor when rules on where data lives, network isolation or custom infrastructure require you to control the environment, or when your team already runs Docker or Kubernetes and can absorb another production stack. The choice turns on control requirements and operating capacity. Feature lists rarely settle it, because most of the decision is about who runs the platform for years.
Saleor Cloud is the better fit when no one on the team can own on-call coverage for a commerce stack. Pricing follows monthly GMV: the Select plan lists 1,599 US dollars per month for up to 200,000 dollars of monthly GMV plus 0.8% above that, and the Volume plan lists 3,999 US dollars per month for up to 1 million dollars in GMV plus 0.4%. Enterprise pricing is custom. Before signing, confirm how the vendor measures GMV, what each tier includes, which hosting regions are available, and how upgrades and support are handled. Cloud also removes the work of running the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers yourself.
Self-hosting fits when data location rules, network isolation or custom infrastructure dictate the environment, or when your team already operates Docker or Kubernetes. You run every component in your own accounts, so your staff takes on patching, backups, scaling and upgrades, and that cost recurs every month. The Docker Compose setup asks for at least 5 GB of memory for Docker, which only sets a minimum for a trial environment and says nothing about production capacity. Configuration uses environment variables, so it can sit inside your existing secrets and deployment tooling. Have the security owner write down control requirements and name the on-call owner before choosing, then test a deployment in staging with your own data flows. Setup details are in the Saleor Docker Compose documentation.
How the two models compare on licensing, features and cost structure
This table compares Saleor Cloud and self-hosted Saleor factor by factor, from license and hosting responsibility to published plans and features. Read the cost row as a question of who pays for what over time, and confirm Cloud feature availability for the plan you are considering.
| Factor | Saleor Cloud | Self-hosted Saleor |
|---|---|---|
| License | Managed service under Saleor's Cloud terms. The hosted service is not the same thing as the BSD-3-Clause source code. | Open-source code is BSD-3-Clause licensed, so you can run, modify and distribute it under that license. |
| Who runs the API and Dashboard | Saleor operates the hosted API and Dashboard for you. | Your team deploys and operates the API and Dashboard, typically with Docker Compose or your own orchestration. |
| Who runs PostgreSQL, Valkey or Redis and Celery | Managed as part of the hosted service. Confirm backup, restore and failover terms in your contract. | Your team provisions and maintains PostgreSQL, Valkey or Redis and Celery workers, including upgrades and monitoring. |
| Published plans | Free Sandboxes. Select at 1,599 US dollars per month (Saleor pricing page) covers up to 200,000 dollars monthly GMV plus 0.8% above that. Volume at 3,999 dollars per month covers up to 1 million dollars plus 0.4%. Enterprise is custom. | No license fee for the code. Infrastructure, staffing and support are paid to your cloud provider, your team or a partner. |
| Recurring versus one-time costs | Plan fees and GMV-based charges recur monthly. Migration work is typically one-time. | Hosting, storage, monitoring, security testing and upgrade effort recur. Initial deployment and integration are largely one-time. |
| Cost drivers | GMV volume, plan tier and any Enterprise terms. Ask how overage and GMV measurement are calculated. | Environment size, high availability design, staffing hours and the number of integrations. Ask for an itemized quote from any implementation partner. |
| Core commerce features (GraphQL API, channels, multi-warehouse, promotions, split payments) | Confirm availability and edition for each feature on your chosen Cloud plan before committing. | Included in the open-source code as documented in the repository, subject to your version and configuration. |
Where data lives and what compliance evidence you must produce
Saleor Cloud and self-hosted Saleor place the same API, Dashboard, database and workers in different trust boundaries. The cards below cover where data sits, who holds administrative power, how payment and customer data are contained, how patches arrive, and what evidence an assessor will ask for in each case.
Data location and residency
With Saleor Cloud, the PostgreSQL database, media and the running services sit in Saleor's managed hosting, so the hosting regions and sub-processors are a contract question rather than your decision. Self-hosting with Docker places every component in your own cloud account, data center or air-gapped network, which lets you set residency yourself. Ask Saleor Cloud in writing which regions host your store, where backups are kept, and which sub-processors touch order data.
Access and administration rights
On Cloud, Saleor's operators administer the infrastructure, and your team administers store configuration through the Dashboard and apps. Self-hosted, your platform team holds root access to the containers, database credentials and the environment variables that configure Saleor. Document who can read the PostgreSQL database directly, who rotates secrets, and who can change webhook targets, because those paths reach customer records even when the storefront is secure.
Trust boundary around payment and customer data
Saleor supports multi-gateway payment handling, so the question is which component touches card-adjacent data and what is retained. Map every webhook and app that receives order or customer payloads, then confirm with your payment providers and with Saleor where tokenization happens. In a self-hosted deployment, the boundary includes your Celery workers and Valkey or Redis instances, which may hold transient order data and must be covered by your own controls.
Change control and patch timing
Cloud customers receive platform changes on the vendor's schedule, while self-hosted teams pick the Saleor release and the timing of each upgrade. Saleor's releases are published on GitHub, and the most recent of them, 3.23.42, dates from October 16, 2026. Record the version you run, the date you applied each release and the test evidence behind it, because assessors ask for change records in both models. Confirm with Saleor which versions receive security fixes and for how long.
Compliance evidence and what DeployOpen prepares
Frameworks such as SOC 2, ISO/IEC 27001 and PCI DSS require evidence from the operator of the system, and that operator differs between the two models. DeployOpen plans, hardens and documents self-hosted Saleor and prepares controls and evidence for assessment, but it does not issue audit reports, attestations or certifications. Ask Saleor for its own current compliance documentation and hosting locations rather than assuming them, then confirm with your assessor which evidence each party must supply.
What your team runs in each model
Saleor Cloud is managed hosting, so Saleor operates the platform and your team works at the level of configuration, data and integration. Your work centers on the GraphQL API, the Dashboard, webhooks and apps, channel and warehouse setup, and the promotions and payment flows your store depends on. You do not install or patch the database, cache or worker processes yourself.
- Operations: the vendor runs the underlying services, so you do not size or patch PostgreSQL, Valkey or Redis, or Celery workers.
- Integration: you extend the store through the GraphQL API, webhooks, apps and metadata, which is the same extension model available to self-hosted installs.
- Pricing: Saleor's pricing page lists plans by monthly GMV, so cost scales with store volume rather than server count.
- Control: you keep configuration and data, but confirm which infrastructure settings, regions and maintenance windows you can influence.
- Exit: the pricing FAQ says moving from Cloud back to open source is supported, with the customer handling the data migration.
Before committing, ask Saleor which data residency, backup and recovery commitments apply to your plan and what the support response terms are.
Self-hosting means your team, or a partner you engage, runs every service in your own infrastructure. Saleor is BSD-3-Clause licensed and built on Python, Django, GraphQL and PostgreSQL, and it is offered for self-hosting with Docker. The stack you own includes the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers.
- Services: you run and connect the API, Dashboard, database, cache or queue, and Celery workers in every environment.
- Resources: the Docker Compose setup asks for at least 5 GB of memory for Docker, so plan capacity before testing.
- Configuration: Saleor is configured through environment variables following 12-factor app principles, which keeps settings portable between environments but puts secret handling on your team.
- Upgrades: you plan each move onto a newer Saleor release, test it against your extensions and apply it yourself.
- Backups and monitoring: you own database backups, restore tests and service monitoring for every component.
Ask your team who owns each of these services on call, and whether your hosting environment meets the memory and database requirements in the current Docker Compose documentation.
Upgrades are where the two models differ most in day-to-day work. On Cloud, the vendor applies platform changes on its schedule, and your team validates your storefront and integrations against them. Self-hosted, you choose when to adopt a release, so you must schedule, test and roll back changes that touch the API, Dashboard, database migrations and background workers.
- Release tracking: Saleor publishes releases on GitHub, such as 3.23.42 released on October 16, 2026, so track the release line you run.
- Testing: self-hosted teams need a staging environment that mirrors production data shape, webhooks and apps.
- Extensions: apps and webhooks should be checked against each new release, because they are the main integration surface.
- Support windows: confirm the support and upgrade windows for the version you intend to run with Saleor, since these are not set out in the facts used here.
- Ownership: on Cloud, the vendor carries platform patching; self-hosted, your team or partner carries it.
Ask Saleor for written support and upgrade commitments for your plan, and map them against your own change-control calendar.
How GMV-based Cloud pricing and self-hosting costs add up
Saleor Cloud costs follow your gross merchandise value, not your server count. The published Cloud plans are Select at 1,599 US dollars per month, covering up to 200,000 dollars of monthly GMV plus 0.8% above that, and Volume at 3,999 dollars per month, covering up to 1 million dollars plus 0.4% above that, according to the Saleor pricing page. Enterprise is custom. So the recurring bill has two parts: the plan fee and a percentage of GMV beyond the plan ceiling. Your GMV growth is the main driver of tier movement. A merchant whose monthly GMV is climbing toward the Select ceiling should model when the percentage starts to dominate the bill, and when the next tier becomes cheaper. Confirm with Saleor whether GMV is measured monthly and how refunds, currencies and marketplace flows are counted before you build that model.
Self-hosting moves the bill from a vendor invoice to your own operating cost, and most of it recurs. The Saleor setup needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and the Docker Compose documentation asks for at least 5 GB of memory for Docker. Those are the infrastructure lines. Staff or partner time covers upgrades, security patching, monitoring, backups, restore tests and on-call coverage for payment and order workflows. None of these lines has a published figure from Saleor or from DeployOpen, so there is no number to compare directly against the Cloud fee. Build a bill of materials from your own environment and ask for each line to be costed.
Ask for specific written inputs before comparing the two totals. From Saleor, request an Enterprise quote that states the GMV basis, the plan ceiling and percentage, support and uptime terms, data residency, and the cost of any migration from or to open source, which Saleor's FAQ says the customer handles for data migration when leaving Cloud. From a partner, request a fixed-scope estimate listing the components to be deployed, the upgrade cadence, backup and restore testing, monitoring and hardening, and the handover documentation. Ask both sides which costs are one-time and which recur, and ask what changes in each total if GMV doubles.
Moving from Saleor open source to Cloud and back again
This sequence shows how a team moves a Saleor store from self-hosted open source onto Saleor Cloud, and how it moves back if the hosting decision changes. The first direction depends on version compatibility, while the return direction places the data export, environment rebuild and integration rework on the customer.
Confirm the Saleor version is compatible with Cloud
Before any planning, the platform or engineering lead checks the running Saleor version against what Saleor Cloud accepts for migration. Saleor's pricing FAQ says a move from open source to Cloud is possible on a compatible version, so this check comes first and can change the schedule. Ask Saleor to confirm the compatible versions in writing, and record the exact release you run in production, including any custom apps or API extensions. The output is a short compatibility note that names the version, the extensions in use and the vendor's confirmation.
Inventory apps, webhooks, metadata and integrations
The team lists everything that connects to the store: webhooks, installed apps, metadata fields, payment gateway configurations, fulfillment and ERP connectors, and any custom code that calls the GraphQL API. Saleor extends through webhooks, apps and metadata rather than in-process plugins, so this inventory is the real scope of the move. The owner for each item is named, and each one is marked as portable, needs rework or is retired. The output is a dependency register that drives the cutover plan.
Export schema and data from the open source database
The database owner exports the PostgreSQL schema and data that Saleor Cloud needs, including products, channels, prices, warehouses, orders, customers and promotions. The customer carries this data migration in the open source to Cloud direction, so the work belongs to the team or its implementation partner, not the vendor. Confirm with Saleor which export format and sequence it requires, and whether media files and search indexes move separately. The output is a verified export set with row counts and checksums compared against the source.
Stand up and load the target environment
The platform team provisions the target environment, either the Cloud project or a rebuilt self-hosted stack, and loads the exported data into it. A self-hosted target needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, and Saleor's Docker Compose setup asks for at least 5 GB of memory for Docker. Configuration is set through environment variables, so the team records every value in a controlled store rather than in local files. The output is a running environment that starts cleanly with the loaded data.
Re-point integrations and re-register webhooks and apps
Payment gateways, shipping providers, ERP and warehouse systems, storefronts and internal tools are pointed at the new API endpoint. Webhooks and apps are registered again in the target environment, because their registrations and secrets do not carry over automatically in the way the team might expect. Each connection is tested with a non-production transaction. The output is a signed-off list of integrations, each showing the endpoint, the registration and a passing test.
Test cutover and plan the rollback path
The team runs test orders through checkout, payment capture, returns, multi-warehouse fulfillment and promotions, then compares results with the source system. Cutover planning and testing are the main effort drivers in either direction, so this step usually takes the most time and needs a named owner for go or no-go decisions. A rollback path is written and rehearsed, including how orders placed after cutover are reconciled if the team must return. The output is a test record and an approved cutover runbook.
Reverse the move when returning to open source
To move from Cloud back to open source, the team exports data from Cloud with the customer handling the data migration, as Saleor's pricing FAQ describes. The work then repeats the same steps in reverse: rebuild the self-hosted environment, load the data, re-point integrations, and re-register webhooks and apps. Confirm the Cloud export format and any data Saleor does not export before planning. The output is a self-hosted store with a documented reconciliation of orders, customers and inventory against the Cloud source.
Questions buyers ask before choosing Cloud or self-hosting Saleor
What drives the cost of Saleor Cloud compared with self-hosting?
Saleor Cloud costs follow the plan you choose and your monthly gross merchandise value (GMV). Saleor's pricing page lists free Sandboxes, Select at 1,599 US dollars per month covering up to 200,000 dollars of monthly GMV plus 0.8% above that, Volume at 3,999 dollars per month covering up to 1 million dollars plus 0.4%, and custom Enterprise pricing. Self-hosting shifts the spend to infrastructure and people: cloud accounts or servers for the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers, plus the engineering time to patch, monitor and upgrade them. Ask Saleor how GMV is measured for your store, and ask a partner for a written quote covering setup, hosting, and recurring maintenance separately.
How much effort does a self-hosted Saleor setup take to stand up?
The effort depends on how many services you run and who operates them. A self-hosted Saleor deployment needs the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers. Saleor's Docker Compose setup asks for at least 5 GB of memory for Docker, which is a development starting point rather than a production sizing. Plan for configuration through environment variables, network and secrets setup, backups, monitoring, and a tested upgrade path. Ask your team to estimate those tasks against your own environment, and treat any timeline from a vendor or partner as something to confirm in writing.
Can a small team run self-hosted Saleor without outside help?
A small team can run it alone only if it already operates PostgreSQL, container platforms, background job workers and a commerce data model. Saleor exposes everything through a GraphQL API and extends through webhooks and apps, so integration work is mostly code and configuration rather than in-process plugins. The harder parts are on-call coverage for payments and orders, security patching, and upgrades across Saleor releases. Be honest about those gaps. A fixed-scope engagement from DeployOpen can plan, implement, harden, back up, upgrade and document a self-hosted platform inside your own infrastructure, and ongoing support is available as a retainer.
Can Saleor data stay in a specific region or private network?
Self-hosting gives you direct control over where the database, media and logs live, including private networks and cloud accounts in a chosen region. Saleor Cloud is managed hosting, so confirm with Saleor where customer data is stored, which subprocessors touch it, and what contractual terms apply before you sign. Ask specifically about backups, support access to production data, and audit logging. If your residency rules are strict, confirm them against your own legal and compliance requirements rather than relying on a vendor summary.
How do you move from Saleor Cloud back to open source?
Moving from Cloud back to open source is supported, but the customer handles the data migration. Saleor's pricing FAQ says moving from open source to Cloud is possible on a compatible version, so check version compatibility before any move in either direction. Plan for exporting catalog, order, customer and configuration data, rebuilding environment variables and integrations, and reconnecting payment gateways and apps. Ask Saleor which export formats and version constraints apply, and budget a test migration in a staging environment before cutover.
What should we ask Saleor and a partner before signing?
Ask Saleor how GMV is measured, which plan limits apply, what happens when your GMV crosses a plan threshold, what support and uptime terms are included, and how a move to open source would be handled. Ask a partner for a written scope listing deliverables, timelines, responsibilities for patching and upgrades, backup and restore tests, and who holds on-call duties. DeployOpen works from fixed-scope agreements, so the written scope is where cost, timing and ownership should be settled before work starts. Request the Saleor license terms (BSD-3-Clause) and the current release notes for the version you plan to run.
What to confirm with Saleor before you decide
Start by asking Saleor for the facts that the public pricing and repository material does not settle. The first is Cloud hosting regions: ask which regions Saleor Cloud runs in, whether you can pin data residency to a specific country or jurisdiction, and whether backups and logs stay in that region. Your data protection and sector rules decide whether that answer is acceptable, so put the question to Saleor sales in writing and file the reply with your security review. Ask the same for any sub-processors that touch order, customer or payment data.
Next, request the compliance documentation Saleor can share under NDA, and confirm which controls, reports or questionnaires exist and how current they are. Do not assume a certification applies to a given plan. Ask separately about support response commitments, the upgrade windows for Cloud and for Saleor versions you run yourself, and how long a release line receives fixes. On the self-hosted side, your own team sets the upgrade cadence, so compare Saleor's stated window with your change calendar and your PostgreSQL, Valkey or Redis, and Celery worker upgrade plans.
Finally, confirm feature availability per plan. Ask which promotion, payment, returns and multi-warehouse capabilities are included in Select, Volume and Enterprise, and whether any app or webhook integration you need carries a separate charge. Request Enterprise terms in writing, including exit terms, data export formats and the process for moving back to open source, since the migration itself is handled by the customer. Use the answers to build a dated decision record, and send any gap to your own legal and security owners before you sign.
How DeployOpen scopes and runs self-hosted Saleor
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Saleor, that means turning the Cloud or self-hosted decision into a written scope covering the API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers before any work starts.
How we scope
- Written scope listing which Saleor components you will run: API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers.
- Agreed hosting targets, environments, channels, warehouses and payment gateways that the self-hosted build must cover.
- Confirmed upgrade path to a Saleor version compatible with your current data and extensions, before deliverables are fixed.
How we build
- Deployment of the Docker-based stack with configuration held in environment variables, following 12-factor practices.
- Webhook and app extensions for your integrations, since Saleor extends through apps and webhooks rather than in-process plugins.
- Security testing and hardening of the API and Dashboard, with the results recorded against the agreed scope.
How we hand over
- Runbooks covering backups, upgrades, scaling of workers and database maintenance in your own environment.
- Architecture and configuration documentation, so your team can operate the platform without relying on us.
- Documented steps for any future move between self-hosted Saleor and Saleor Cloud, including the data migration responsibilities you hold.
How we support
- Fixed-scope engagements with deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous testing available as a retainer, scoped to your Saleor version and extensions.
- Quotes follow from the written scope, so ask us to itemize the components, environments and testing included.
