Saleor installation: where self-deployment breaks
Doing a Saleor installation yourself looks like a routine Django project deployment: bring up the application, apply migrations, connect the database and cache.
Things usually break not at this step but at the junctions—when the store starts operating under real traffic and with external systems.
The first layer of failures is the catalog. Products, variants, and stock come from the accounting system, while product pages are also edited in the admin: without an unambiguous data owner, each synchronization overwrites someone else's edit.
Items with zero stock and an old price appear on the storefront, and the discrepancy between the storefront and checkout surfaces at the moment of payment.
The second layer is the cart and orders. If checkout goes through several steps without a single transaction and without stock reservation, during peak load on a sale day some carts are lost and orders are duplicated.
The customer sees one charge, the warehouse sees two requests, and investigation takes a day, not minutes. The integrity of the catalog and orders rests not on retries but on idempotent operations and explicit stock locks.
The third layer is integrations: payment, delivery, warehouse, and mailings.
At peak they receive many times more requests, and without queues with concurrency limits, background tasks pile up, notifications from external systems are lost, and order statuses stop matching actual shipment. Below we look at how this is addressed when deploying an ecommerce platform.
Flexible catalog and order schema: what configuration provides
A product page is not a single record but a set of variants: color, size, configuration, each with its own stock and price.
A correct catalog data model explicitly links variants, warehouses, and sales channels, so the storefront serves only what is available in the required channel.
In Saleor, this schema is built in by default but requires configuration—otherwise duplicate products appear and the storefront and warehouse diverge.
Catalog, variants, and warehouses
We describe attributes with typed fields, not free text: filters and selections are built from indexes, not by brute force. We build categories as a tree with predictable depth so that category output does not pull the entire catalog.
We separate reservation from actual stock: until an order is confirmed, the item remains available to other customers, and the warehouse does not show a “minus.”
Storefront layer and peak loads
The storefront layer assembles the catalog page from prepared queries instead of a cascade of requests: response time drops to fractions of a second instead of seconds and does not grow with catalog depth.
We check peak throughput with runs on a real profile—sale, ad campaign, seasonal spike—and bring it to a state where the storefront handles the flow without a queue.
Checkout proceeds as a single operation: stock deduction, order creation, and status history recording do not diverge from one another. Re-submitting the form does not create a second order, and a break at the payment step does not leave a frozen reservation.
A class of failures goes away: “sold something that isn't there” and “the order exists but the items don't.”
Deployment modes: comparing options
The choice of deployment option determines how quickly a Saleor update is released, how predictably the application will survive catalog growth, and who is responsible for data access. Below are three schemes that are realistically chosen between at the start.
| Option | When it fits | Option limitations |
|---|---|---|
| On-premises hosting | Requirements to keep data and access within your own infrastructure, you have your own operations department, a non-standard network scheme | Updates and scaling are performed manually, database migrations are planned as a separate operation with downtime or replica switching |
| Containerized scheme | Need regular releases, horizontal scaling of the storefront and background tasks, development environment mirrors the production environment | Without metric and log collection, incident investigation time grows; an infrastructure team and rollout procedure are required |
| Managed platform | Fast launch, small team, no need to keep an operations engineer | Some parameters are unavailable, updates and migrations are tied to the provider's procedure, depth of layer configuration is limited |
What changes when scaling
In the containerized scheme, the application layer is stateless, so the storefront scales with replicas, while the background task queue is moved out separately and grows independently.
GraphQL requests are cached, heavy catalog queries go to database replicas—the cart and checkout remain on the primary node.
Switching between options is done by transferring a database dump and media files, so the chosen scheme does not lock you in: we work out which environment covers your access and load constraints.
Saleor installation procedure: from audit to handover
The work sequence is structured so that each step relies on the result of the previous one: first we record the actual state of the environment, then design the scheme, and only then touch the production environment. Below are the implementation stages as they proceed on projects with live traffic.
- Infrastructure survey. We capture the current picture: service placement, database design, server limits, and tools used by the team. The output is a report with bottlenecks that directly affect the deployment scheme.
- Scheme design. We determine the composition of Saleor components, the data storage scheme, service roles, and integration points with the accounting system and payment. We agree on the topology before work begins.
- Environment separation. We set up separate environments for development, acceptance, and production—each with its own databases, keys, and configuration. Updates are tested on a data copy and do not affect customers.
- Installation and configuration. We deploy the application, background task queues, search index, and cache, configure migrations and backups—first in the test environment.
- Load testing. We model real scenarios: catalog browsing, cart, checkout, exports. We look at response time under peak and system behavior when an individual node fails.
- Project handover. We hand over access and documentation for deployment and recovery, train the team, fix the update procedure, and remain on support.
Delivery package: configurations, schemas, and procedures
The delivery is not an archive with code but a set of artifacts by which the system can be operated and developed without the author.
Everything configured during Saleor installation is recorded in the repository and documentation: configurations, schemas, policies, and procedures are transferred to the customer.
- Project configurations — environment files for development, test, and production environments, database and queue connection variables, secrets moved out separately.
- Integration schema — a map of connections with payments, delivery, warehouse, and the accounting system: exchange direction, data format, behavior when the external side is unavailable. The API by which the storefront and mobile application connect is described separately.
- Access policies — roles and permissions for orders, catalog, and prices; restrictions on admin login and service methods.
- Data schema and migrations — catalog structure (products, variants, collections, warehouses), population rules, and migration order from the previous system.
- Update procedure — frequency of platform and dependency updates, testing in the test environment, rollback points.
- Monitoring and logs — collected metrics, alert thresholds, notification routing.
- Documentation and acceptance checklist — instructions for administrators and developers, verification scenarios before rollout.
This composition removes dependence on the contractor: a new engineer enters the system using schemas and procedures, not the previous team's memory.
Case study: migrating a catalog without stopping sales
A store on an old platform had a catalog of 40+ thousand items, and stock synchronization ran in batches and blocked the storefront: the export took up to 40 minutes, during which product pages would not open, and managers processed some orders manually.
Stock and price discrepancies reached 8% of items—support dealt with them daily instead of focusing on customers.
The migration was done without stopping sales. The new Saleor environment was brought up in parallel with production: the catalog and order history were transferred in write batches, while the old store continued accepting orders.
While loading proceeded, concurrent changes came in incrementally, and idempotency keys prevented duplicates from entering the catalog.
What changed
The storefront switch went without downtime: customers saw neither a maintenance page nor checkout errors, and returning to the old environment in case of deviation could be done with one command.
Catalog response time for heavy filters decreased by almost three times—the index and cache are rebuilt in the background, not on every request.
Metrics afterward
- Store downtime: zero instead of a planned several hours.
- Catalog export: from 40 minutes to a few minutes, the storefront remains available.
- Support requests for “item unavailable / wrong price”: four times fewer.
- Stock discrepancies: from 8% of items to fractions of a percent.
The freed-up support time went to consultations and work with wholesale customers, not to investigating discrepancies. Connecting a new sales channel now does not require a separate export—the catalog comes from a single source.
How does deployment from scratch differ from store migration?
Deployment from scratch is a clean Saleor installation: we design the catalog schema for the task rather than inheriting it from the previous platform.
Attributes, product variants, warehouses, and pricing rules are set directly in the required model, and integrations connect to an empty database. The scope of work is configuration and scenario verification, not migration.
Store migration is the reverse task: preserve a working business at the moment of platform change. We migrate the catalog, categories, attributes, stock, order history, and users.
The main difficulty is the mismatch of the catalog schema: what was a single entity on the previous platform is decomposed into several here and requires explicit transformation.
Data migration goes through an audit: what we transfer as is, what we rebuild, and what we do not take. The export goes in a neutral format, and the load is done with convergence checks: item count, stock, prices, and order linkage must match before and after. We look for discrepancies in the test environment, not on the production database.
Integration compatibility is the second major migration risk. Payment gateways, delivery services, the warehouse, and accounting exchange data according to their own contracts: some connect with standard tools, and some require custom development. We redirect old product and category URLs to new ones with permanent redirects.
The conclusion follows: deployment from scratch is predictable in terms of timeline; migration—stages and a rollback plan. With a small catalog and few connections, a clean installation with data reload is faster.
Platform limitations and common technical questions
The platform covers the catalog, cart, and checkout out of the box, but it has boundaries—it is better to know them before launch. Below are the doubts most often voiced during estimation and how we address them at the architecture level.
Where is the catalog limit and how does the storefront behave at peak?
The limit is set not by the number of products but by indexing and cache: tens of thousands of items with facet filters go into a separate search layer. Queries are limited by depth and cost so that a heavy call does not occupy a worker, and the application scales horizontally. The cart and checkout remain responsive during a promotion.
How do the warehouse and accounting system connect?
Stock, prices, and order statuses flow through the API—on a schedule and by events. We fix source priority in advance: the warehouse dictates stock, the store dictates price, and discrepancies go to the log and do not turn into selling an unavailable item.
What about payments and security?
The gateway is connected by configuration, and payment goes with 3-D Secure confirmation.
Card data does not pass through the application—tokenization on the provider side is used, so the audit scope remains narrow, and the payment provider can be changed without rewriting the storefront.
In what order are platform updates released?
We do not roll out a new major branch on release day: first an intermediate staging environment, a run of order scenarios and data migrations, then rollout with rollback capability. Updates are released in batches.
Let's discuss the task: what is needed for estimation and start
To discuss the task substantively and come back with a project estimate rather than generalities, we need the scope of work. Below is the minimum set of input data.
If something is not available yet—not critical: we will clarify some on a call and gather some ourselves during the analysis.
- Catalog: how many products and categories, which attributes and variants (sizes, options), and where we migrate data from.
- Sales model: one storefront or several, languages and currencies, whether different warehouses and delivery rules are needed.
- Payment and logistics: which payment providers and delivery services we connect, whether there are non-standard scenarios such as partial payment or pickup.
- Integrations: ERP, warehouse, CRM, analytics—what should exchange data with Saleor and in which direction.
- Load: expected peak traffic, number of concurrent shoppers, requirements for catalog and checkout response time.
- Infrastructure: where we host the project, what environment exists now, who is responsible for access, domains, and certificates.
- Constraints: launch date, obligations to partners, what is already ready for content and layouts.
Based on this, the engineering team fixes the scope, breaks it into stages, and provides a work plan and timeline with explicit assumptions and approval points. Describe the task in any convenient form—we will come back with an estimate and plan.
