Vendure installation: what breaks in a store's production environment
A store's production environment breaks not at launch, but under peak load.
When a sale coincides with a mailing to the customer base, the catalog assembles every filter listing from dozens of database calls, the connection pool stops keeping up, and response time grows nonlinearly: some carts lose selected items, and the customer lands on an error page.
The same catalog bottleneck surfaces when recalculating discounts and stock — a heavy task runs in the same process as page rendering.
The second breakdown is stuck payments.
The gateway charged funds, confirmation didn't arrive or was processed twice, the order remained in an intermediate status: the item is not reserved, the refund is done manually, and reconciliation with the provider runs on daily exports when discrepancies have already accumulated for several days.
The third is manual edits during updates.
Modules, the data schema, and checkout are edited directly on the production server because it's faster; after the next release the changes are overwritten or diverge from the repository, and the update turns into a night operation with manual rollback and running scenarios off a paper checklist.
Installing Vendure on a separate environment removes all three nodes.
The catalog is served from warmed cache, heavy tasks — indexing, price recalculation, emails — go to separate workers via a queue, payment confirmations are processed idempotently, with retries and a discrepancy log, so a webhook repeat doesn't create a second order.
Edits live in the repository: migrations are versioned, environment settings are moved out of code, and the build and schema are checked before rollout.
We break down how this is covered: from server and role preparation to queues, cache, and pre-publication checks.
What a well-built store delivers: speed and fault tolerance
A store built on Vendure is one predictable environment: catalog, cart, checkout, and admin run on a shared set of models and contracts.
Therefore catalog response time doesn't grow with sample size: filters and pagination are calculated by the database, while heavy aggregates are served from warmed cache. A list of hundreds of items opens as quickly as a single product card.
Fault tolerance here is a set of decisions, not a promise: multiple application instances behind a load balancer, dedicated background handlers for emails, exports, and stock synchronization, separate database connection pools for storefront and admin.
If a node goes down, traffic moves to a live instance, and recovery time is measured in minutes, not hours of downtime.
Along with this, a whole class of failures goes away, the kind that usually surfaces at peak: stock desynchronization between storefront and warehouse, double checkout of a single order when the form is resubmitted, lost cart items after a restart.
This is covered by database-level transactions and repeatable checkout operations — order status does not depend on whether an external service managed to respond.
Load resilience is tested not with synthetic traffic but with a sale: we limit the number of parallel heavy queries, cache the catalog and categories, and keep checkout on a separate pool.
The storefront under load doesn't slow down payment, so the share of orders completed to payment without retries and errors stays steady even during peak hours.
Deployment options: own server, managed hosting, hybrid setup
Hosting a Vendure store is determined not by catalog size, but by who is responsible for core updates, backups, and scaling during peak hours.
The application requires a process manager, database, background task handler, and media storage — you can assemble this yourself, hand it to a provider, or split environments. Below are three working schemes and their limitations.
| Option | When it fits | Limitations |
|---|---|---|
| Own server | Full control over the environment, own access rules, and placement in a specific jurisdiction are needed | OS patches, application updates, and backups are on your side; a configuration error causes downtime without external support |
| Managed server rental | No dedicated engineer, quick launch and predictable basic operations are needed | Lower load ceiling, restrictions on long-running background tasks and queue size, maintenance windows are set by the provider |
| Hybrid setup | The provider handles the storefront and admin, while heavy tasks — media processing, exports, exchange with the accounting system — are moved to a separate environment | More complex network and access rights; uniform build rules and identical environment variables across all environments are mandatory |
The scheme is fixed before data migration, not after: the deployment method, backup points, and rollback order depend on it.
At the assessment stage, we compare the chosen option against the load profile and check that background tasks and the database won't become a bottleneck as the catalog grows.
Vendure installation step by step: from audit to handover
The work order is structured so that each decision relies on facts from the previous step.
First we record what already works in the environment, then design the scheme — and only then touch the production environment, so installation doesn't turn into a series of emergency edits.
- Environment audit. We review servers, database, cache, queues, DNS and certificates, current limits and failure points. The output — a map of what we reuse and what we change.
- Deployment scheme. Determine where the application, database, media, and background tasks live, how requests travel between them, and where the session is lost. We agree on the scheme before the first command on the server.
- Access rights. Separate system user, secrets and environment variables placed across directories, database roles by least privilege: the application does not run as superuser.
- Installation and configuration. Deploy the current Vendure branch, run migrations, connect plugins and queue handlers, configure cache and catalog indexing.
- Load testing. Run customer scenarios — search, cart, checkout — on a profile close to real traffic, and review response time and database behavior under peak.
- Backups and rollback. Set up regular snapshots of the database and media and verify restoration on a separate staging environment, not just the fact that a copy was created.
- Project handover. Provide documentation, update regulations, scheme breakdown, and access to your team.
The output is a working environment and a clear set of actions for an update or failure.
What you keep: configurations, diagrams, regulations, access
We deliver not only a working server, but the entire surrounding framework: deployment configurations, infrastructure diagrams, regulations, and access.
The package is assembled so any other team can accept it — without our verbal explanations and without reconstructing decisions from memory.
- Deployment configurations — environment files, application build and launch parameters, catalog, cart, and checkout settings with an explanation of what each value affects.
- Infrastructure diagrams — what is located where: application server, database, cache, queues, external services, how they are connected, and where the failure points are.
- Update regulations — procedure for releasing a new version, rollback procedure to the previous one, checklist before and after deployment.
- Backups — schedule, copy retention depth, restoration verification regulations, and the procedure for restoring from a copy in a clean environment.
- Access and roles — list of accounts, permission levels, secret storage location, and planned rotation procedure.
- Documentation — map of code and plugins, description of non-standard solutions, changelog and known limitations indicating what was done this way and why.
- On-call team instructions — how to read logs, which metrics to consider normal, and what signs should trigger an alert.
A separate block is documentation on customizations: what exactly we extended in Vendure, where plugin code lives, how to update them along with the core, and what breaks if an intermediate version is skipped.
Such a package can be handed to an external contractor or used to assemble your own team — work continues from the same point, not from re-studying the system.
Case study: store stopped losing orders under peak loads
Before migration, a store with a catalog of 12,000 items couldn't handle peak: on sale days up to 4% of orders were lost. Customer payment went through, but the order record wasn't created — investigation fell to support. Updates were deployed at night, stopping order acceptance for 40 minutes.
What we changed
The catalog was migrated with reconciliation: exported via the old platform's API, verified item count, stock, and category binding, preserved cross-reference identifiers — page URLs and search positions didn't shift.
The store was deployed on the current Vendure branch in a configuration with multiple application nodes.
Order and stock deduction are written in one transaction, the attempt has an idempotency key: resubmission doesn't create a duplicate, and a failure rolls back the order entirely.
Cart and sessions were moved to shared storage — a process restart no longer resets the customer mid-checkout. Deployment goes sequentially to reserve nodes, traffic returns after a readiness check, so an update is no longer a downtime window.
The result
| Metric | Before | After |
|---|---|---|
| Lost orders at peak | up to 4% | 0 |
| Downtime during update | 40 minutes | without stopping |
| Category page response | 1.8 s | 0.4 s |
| Orders reaching confirmation | 96% | 99.8% |
Under comparable sale load, not a single order was lost, and support stopped handling "paid but didn't arrive" complaints. Next we break down how such a configuration is assembled from scratch.
What to do if the store already runs on another platform?
We migrate an active store in two environments: the old one continues accepting orders while the new one on Vendure and NestJS is filled with catalog and tested in test mode.
Sales don't stop during import or reconciliation — downtime is reduced to a short write window at switchover.
We import the catalog from the old platform export: match SKUs, variants, attributes, categories, media, and translations by keys, not names.
Import is idempotent — a repeated run updates records rather than creating a second card for the same product, so discrepancies can be resolved iteratively without breaking already migrated data.
Order and customer history is migrated in a separate pass and kept read-only: statuses, totals, items, and customer links. This keeps reporting, repeat purchases, and returns on old orders working without intersecting with the new accounting.
While migration is underway, stock and prices are pulled from the old platform as deltas by modification time — the new environment sees the current picture, but the old store closes sales.
We switch over during low traffic: short write window, final delta, traffic cutover, and order reconciliation by counters. The old environment remains a hot standby and rollback channel until discrepancies reach zero.
Separately, we put into the registry what is not migrated automatically: certificates, promo codes, and bonus balances. We agree on their migration before switchover — otherwise after launch there will be discrepancies in discounts that must be resolved manually on live orders.
Common concerns before starting: load, access, updates
Concerns before starting are usually the same: will the platform fit the current stack, will the catalog withstand peak load, who changes what in admin, how updates happen, and what remains after a failure.
Will the platform fit our current stack?
Vendure is a NestJS application, extensions are written as regular modules of this framework. Developers stay in familiar layers and the migration scheme instead of learning a separate plugin language. We connect external systems through the platform's standard API.
Will the catalog withstand peak load?
The catalog for reading is served through cache, so category and product card output doesn't hit the database on every request. Filters, collections, and search go to a separate service.
Before launch we run a load test at peak profile and review catalog and cart response time during a traffic spike.
How are access rights separated?
We describe roles by operations: content manager edits cards and media, merchandiser — prices and stock, support sees orders but doesn't change the catalog. Admin login is through corporate authorization, changes go to the log: you can see who unpublished a product and when.
In what order are updates released?
Scheduled updates are installed in an agreed window: first a copy of the production database, run migrations and checks on it, then deployment. Major upgrades are done as a separate stage with extension checks. Rollback returns the previous build and database schema, so the window doesn't stretch all night.
What about backups?
Daily database dump and media snapshot are stored outside the main environment, separately from production. Once a quarter we deploy a copy on a test environment: a copy that has never been restored doesn't count as a copy. Therefore return to working state is measured in minutes.
Let's discuss the task: where we start and what we need from you
We start the conversation with a task review: what already works, where the bottlenecks are, and what result is needed.
It's important for us to understand not just "an online store is needed," but how your catalog is structured, who works with it daily and how, and which processes are breaking now.
Based on the results, we come back with an estimate and plan — with stages, deployment order, and points where your decision is required.
For the estimate to be substantive rather than a "rough guess," we need the minimum from the customer:
- access to the repository or an archive with current code and environment settings;
- infrastructure description: where we deploy, whether there are restrictions on network, access, and backups;
- list of integrations — payment acceptance, delivery, warehouse, accounting system, mailings;
- catalog structure: categories, product variants, languages and currencies, discount and promotion rules;
- expected load: how many items in the catalog and what peak orders per day;
- a person responsible on your side — who accepts the work and approves disputed points.
This is enough to assemble a plan: environment preparation, Vendure installation on NestJS, data migration, integration connection, load testing, and launch.
We provide timelines by stages, not as a single figure — this shows what depends on what and where we are waiting for your data. Describe the task — we'll come back with an estimate, plan, and questions that should be closed before start.
