DEV Community: Serhiy K

Anatomy of a Magento Card Skimmer: How Injected JavaScript Steals Cards — and Why Uptime Checks Miss It

Serhiy K — Wed, 16 Sep 2026 09:39:12 +0000

A Magento store can be fully up, fast, and passing every uptime check while quietly sending each customer's card number to a criminal. Nothing looks broken. Orders complete, pages load in 400ms, the status page is green — and card data is being copied at the moment it's typed.

That's a card skimmer. It's one of the most common and most damaging things that happens to a Magento store, and it's built from the ground up to be invisible. This post walks through exactly how a skimmer gets in, what the injected code does, why traditional monitoring can't see it, and how to catch and remove one.

What is a Magento card skimmer?

A Magento card skimmer — a form of Magecart or digital skimming attack — is malicious JavaScript injected into a store's frontend that reads payment and personal details from the checkout form and sends them to an attacker-controlled server. The customer sees a normal checkout. The order goes through. The card just gets stolen on the way.

The important part for anyone running a store: a skimmer doesn't break anything visible. It adds a small, silent listener to a page that's otherwise working perfectly. The store keeps returning HTTP 200, the page stays fast, and no PHP exception is ever thrown. Detection is hard precisely because, by every conventional signal, the store looks healthy.

How a card skimmer gets into a Magento store

The attacker's goal is simple: get their JavaScript to execute on your checkout page. Magento offers several routes to that, and most of them live in the database rather than in your codebase — which is why redeploying from clean git often doesn't remove a skimmer.

core_config_data. Magento has admin fields whose contents are rendered into every page: the "Miscellaneous HTML" boxes (header/footer), the head includes, tracking-script fields. A single row in core_config_data can inject a script store-wide. This is the single most common Magento skimmer vector.
CMS blocks and pages. A widget or static block that appears on many pages — a footer block, a promo banner — is edited to carry the payload. It renders wherever the block is placed.
Layout XML and theme templates. After a server or admin compromise, the attacker edits .phtml templates or layout XML directly to add a <script> tag. File-level, so it survives cache flushes but not a clean redeploy.
A compromised admin account or extension. The entry point for most of the above: a reused admin password with no 2FA, or a vulnerable third-party extension that allows content to be written. Recent unauthenticated RCE flaws have let attackers skip the login step entirely.
A third-party or CDN script (supply chain). A legitimate external script the storefront already loads — analytics, a chat widget, a tag manager — is swapped at its source. The store's own database is untouched, which makes this variant especially sneaky.

The attack, step by step

Step 1 — Get in

The attacker gains write access to content: a guessed or phished admin login, an exploited extension, or in the worst case remote code execution on the server. No 2FA on even one admin account is often all it takes.

Step 2 — Inject the skimmer

They add a few lines of JavaScript to one of the injection points above — most often a core_config_data field or a CMS block, because those render site-wide and don't require touching the filesystem. The payload is usually obfuscated so it doesn't read as "skimmer" to a casual glance.

Step 3 — Harvest at checkout

The script waits for the checkout page. Many skimmers check the URL and only activate on /checkout to reduce their footprint. They read the payment and address fields — card number, expiry, CVV, name, billing address — either by watching keystrokes or by scraping the form just before submit.

Step 4 — Exfiltrate

The harvested data is sent to an attacker-controlled domain, frequently one that mimics a real service (a lookalike of a CDN, analytics, or font host) so it blends into normal network traffic. Exfiltration often rides on an image request or a fetch to a domain that looks innocuous in a list of third-party calls.

Step 5 — Stay hidden

Good skimmers are quiet. They throw no errors, add no visible latency, and often re-inject themselves from a second foothold if the first is cleaned. The store keeps working normally, which is the whole point — the longer it looks healthy, the longer the cards keep flowing.

Why uptime checks — and even APM — are blind to it

This is the part that catches teams out. Every conventional monitoring signal says the store is fine, because a skimmer doesn't touch any of them.

signal                         what it sees          skimmer detected?
----------------------------   -------------------   -----------------
uptime / HTTP check            200 OK, page loads    no
response-time / APM            fast, ~400ms          no
error-rate / exceptions        none thrown           no
synthetic checkout             order completes       no (order still works)
server / infra metrics         normal load           no

An uptime monitor asks "did the page respond?" — it did. An APM tool asks "is it fast, and is the code healthy?" — it is. Even a synthetic checkout that drives a real browser will complete the order, because the skimmer doesn't stop the purchase — it rides alongside it. The failure isn't availability or performance. It's integrity: the page is serving code it shouldn't. Nothing built to watch "is it up?" or "is it fast?" is built to notice that.

How to detect a card skimmer on your Magento store

You can look for a skimmer by hand today. The checks that matter most:

Read core_config_data for script content. Query the config fields that render to the frontend (the Miscellaneous HTML and head-include paths) and look for any <script> you didn't put there, or references to external domains you don't recognise.
Audit CMS blocks and pages. Scan block and page content for inline scripts and unfamiliar external src domains, especially in site-wide footer/header blocks.
List every external script your storefront loads, particularly on the checkout page, and confirm each domain is one you trust. A lookalike domain (a near-miss of a real CDN or analytics host) is a red flag.
Diff your templates against clean git. If layout XML or .phtml files differ from what's committed, something wrote to the filesystem.
Deploy a Content-Security-Policy and watch its reports. A CSP in report-only mode will tell you when a page tries to load or exfiltrate to an unexpected domain — a strong tripwire for skimmers.
Check whether the injection only fires on checkout. Many skimmers are URL-gated, so comparing the scripts loaded on a product page versus the checkout page can surface a payload that only appears where the cards are.

The catch with all of these is that they're point-in-time. A skimmer injected the day after your last manual audit runs for weeks before the next one. Integrity is not a thing you check once; it's a thing that has to be watched.

How Pulsar detects injected skimmers

This is exactly the gap Pulsar is built to close, and it does it in two ways that matter here.

Content-integrity monitoring. Pulsar's content-integrity collector reads the places skimmers actually hide — core_config_data and CMS content — and flags injected <script> tags, unexpected external script domains, and known skimmer signatures. Because it reads Magento's own stored content rather than just fetching the page, it catches the database-resident injection that's invisible from the outside. It runs continuously, so a script added an hour ago is caught in the next check, not at the next manual audit.

A first-class "compromised" status. Most monitoring tools only know two states: up and down. But a skimmed store is up — that's the problem. Pulsar treats compromised as its own status, separate from the uptime SLA, so a store that's serving customers perfectly while leaking cards doesn't hide behind a green "100% uptime" number. A skimmer is a security incident, and it's surfaced as one.

A note on honesty, because this category is still maturing: content-integrity monitoring catches the common Magento vector — code injected into your store's content — extremely well. A skimmer loaded through a compromised third-party script lives outside your database, which is why watching your external script sources (and running a CSP) matters alongside it. No single check is a silver bullet; defence in depth is the point.

How to remove a skimmer and keep it out

Finding it is half the job. Removing it cleanly and closing the door is the other half.

Remove the injected code at the source — the core_config_data row, the CMS block, or the template file. Redeploying from clean git fixes file-level injections but not database ones, so check both.
Assume the admin credentials are compromised. Reset all admin passwords and enforce 2FA on every account, no exceptions.
Patch and audit the entry point. Apply outstanding Magento security patches, review third-party extensions, and check for unauthorised admin users, integration tokens, and API keys created during the breach window.
Rotate secrets if there was server access. If the compromise reached the filesystem, treat app/etc/env.php — database credentials and the encryption key — as stolen, and rotate accordingly.
Add a Content-Security-Policy to constrain which domains can run scripts and receive data, turning the next attempt into a blocked, reported event.
Monitor content integrity continuously so the next injection is caught in minutes, not at the next quarterly audit — or the next chargeback.

Common questions

Can a Magento card skimmer be detected by uptime monitoring?
No. A skimmer doesn't affect availability — the store stays up, the checkout still completes, and every HTTP response is a healthy 200. Uptime monitoring asks whether the page responded; the skimmer doesn't stop it from responding. Detecting a skimmer requires watching the integrity of what the page serves, not whether it serves.

Where do skimmers hide in Magento?
Most often in the database: core_config_data fields that render site-wide (the Miscellaneous HTML and head-include boxes) and CMS blocks or pages. Less commonly in layout XML or .phtml templates after a filesystem compromise, or in a third-party script loaded from a compromised external source.

Why doesn't redeploying from clean git remove the skimmer?
Because the most common injection points are in the database, not the codebase. A clean redeploy overwrites files but leaves core_config_data and CMS content untouched, so a database-resident skimmer survives it. You have to clean the content, not just the code.

Is a card skimmer the same as being "hacked and down"?
No — and that's what makes it dangerous. A skimmed store is fully operational. It's compromised and up at the same time, which is why monitoring that only distinguishes up from down misses it entirely, and why a compromised store needs its own status.

How fast should a skimmer be detected?
As close to immediately as possible — every hour it runs is more stolen cards and more liability. That's the argument for continuous content-integrity monitoring over periodic manual audits: the window between injection and detection is exactly the window in which customers get hurt.

A skimmer is the clearest example of why "is the site up?" is the wrong question. The store is up. It's fast. It's green on every dashboard built to measure availability and performance — and it's stealing cards. Watching the store's integrity, and treating a compromise as its own first-class state, is how you see the failure that every other tool is built to miss.

See how Pulsar monitors Magento →

Magento Deployment Tools Compared: Orbit vs Deployer, Capistrano, Adobe Commerce Cloud & Magefan

Serhiy K — Wed, 02 Sep 2026 10:30:22 +0000

Search "Magento zero-downtime deployment" and you'll get a pile of results that look interchangeable but aren't. A generic PHP deploy script, a Ruby CLI, a six-figure managed platform, a Magento extension, and a purpose-built deploy agent all show up on the same page — as if picking between them is a matter of taste.

It isn't. These five tools sit in genuinely different categories, solve different slices of the problem, and cost anywhere from nothing to a six-figure license. This is an honest look at what each one actually does for a Magento deploy, where it stops, and who each is right for. We build one of them (Orbit), and we've tried to be fair to the other four — including linking you to them.

What does zero-downtime Magento deployment actually require?

Before comparing tools, it helps to name the job. A Magento deploy is "zero-downtime" only if it solves five distinct problems, not one:

Atomic release swap. New code is fully prepared in a separate release directory, and going live is a single instantaneous symlink switch — never an in-place edit of the running site.
The migration window. setup:upgrade can lock database tables. If a migration runs long, requests pile up or error. Something has to either keep the store serving or predict and bound that window.
The build cost. composer install, setup:di:compile, and setup:static-content:deploy are slow, and they re-run on every deploy by default — even when nothing changed.
Rollback. When a release is bad, you need to get back to the previous one fast — ideally automatically, on a failed health check, not by hand at 2 AM.
Visibility and repeatability. You want to see what a deploy did, trigger it from CI, and get the same result every time across every environment.

Keep those five in mind — no single tool below covers all of them the same way.

These five tools aren't the same category

That's the crux, and it's why "which is best?" has no context-free answer:

PHP Deployer and Capistrano are generic deploy orchestrators — CLIs you script to assemble the release structure yourself.
Adobe Commerce Cloud is a managed platform with a deploy pipeline bundled in.
Magefan's module is an in-Magento extension that runs the build in a temporary copy of your store and swaps it in — zero-downtime deploys from inside Magento.
Orbit is a Magento-aware deploy agent built to cover the whole zero-downtime lifecycle.

PHP Deployer

Deployer is the default answer in the PHP world, and for good reason: it's free, open-source, mature, and ships a Magento 2 recipe. It gives you the atomic symlink release structure, shared files and dirs, keep-releases, and a rollback task. If you're comfortable in deploy.php and want full control, it's excellent.

Where it stops is everything beyond the release mechanics. Deployer doesn't hold traffic during a long setup:upgrade, doesn't predict how long a migration will lock the database, doesn't skip build phases whose inputs haven't changed, and doesn't roll back automatically on a post-deploy health check (its rollback fires when a task fails, not when the site comes up broken). It's CLI-only — no dashboard, no team audit log — and the pipeline is yours to build and maintain.

Best for: teams who want a free, scriptable, self-hosted deployer and are happy owning the pipeline.
Watch for: the migration window, build time, and health-based rollback are on you.

Capistrano

Capistrano is the grandparent of atomic-release deploys — Ruby-based, battle-tested, and conceptually identical to Deployer (release directories, symlink swap, rollback). It predates the PHP-native options, so on a Magento (PHP) stack it means running and maintaining a Ruby toolchain and writing your own Magento-specific recipes.

Everything said about Deployer's gaps applies here too: no traffic hold, no migration forecast, no build-skip, no health-checked auto-rollback, CLI-only. If your organisation already lives in Capistrano across other apps, it's reasonable to extend it to Magento. Starting fresh on Magento, most teams now reach for a PHP-native tool.

Best for: shops already standardised on Capistrano across a mixed stack.
Watch for: Ruby toolchain on a PHP project, and all the same lifecycle gaps as Deployer.

Adobe Commerce Cloud

Adobe Commerce Cloud isn't a deploy tool you add — it's the managed platform, with a build-and-deploy pipeline included. If you're already on it, you get an integrated pipeline, infrastructure, CDN, and support in one contract, and you're not assembling any of this yourself.

The trade-offs are lock-in and cost. It only runs on Adobe-managed infrastructure, the pipeline behaves the way Adobe designed it (with its own build and deploy phases), and it comes as part of a license that runs into six figures for many merchants. It's the right answer if you've chosen the Adobe-managed path and want everything in one place — and an expensive answer if all you actually needed was zero-downtime deploys on your own hosting.

Best for: merchants already committed to the Adobe-managed platform.
Watch for: you can't self-host it, and you're paying platform prices for the pipeline.

Magefan's Magento 2 Zero Downtime Deployment module

Magefan's extension takes a different, clever angle: instead of orchestrating releases from an external agent, it works inside Magento. On deploy it copies your live store into a temporary folder, runs the heavy build steps there — setup:di:compile and setup:static-content:deploy (only for enabled themes and locales) — and swaps the finished build in, so the store never drops to a 503 during the build. That's a genuine build-and-swap zero-downtime mechanism delivered as a module, not just a maintenance-page toggle, and it's inexpensive (a commercial license, roughly $119–$303, with 365 days of updates).

Where it stops is the wider deploy platform. It focuses on the build-and-swap for a single store from inside Magento, so there's no pre-deploy DB-migration block-window forecast, no automatic rollback on a failed post-deploy health check, and no cross-environment dashboard or audit log. And because it moves the build off to the side, it targets build-phase downtime specifically — a long setup:upgrade that locks the database is a separate problem it doesn't forecast or hold traffic for. Think of it as a focused, low-cost way to get zero-downtime builds, with the multi-environment orchestration living elsewhere.

Best for: teams who want cheap, in-Magento zero-downtime builds and already have their release/CI approach.
Watch for: DB-migration locks, health-based rollback, and multi-environment orchestration are outside its scope.

Orbit

Orbit is what we build, so read this section knowing that — the facts are checkable against the tools above. Orbit is a small Rust agent you install on your own servers in one command, designed to cover the whole zero-downtime lifecycle for Magento specifically, not just the release swap.

Against the five problems: it does atomic symlink releases; it holds incoming traffic during the cutover so a migration doesn't drop requests; it forecasts the DB-migration block window before you deploy (it diffs the declarative schema, classifies each change as online or blocking DDL, and predicts the lock time — an advisory prediction, not a promise of zero lock); it smart-skips build phases whose inputs haven't changed, turning typical deploys from ~3 minutes to ~75 seconds; and it rolls back automatically on a failed post-deploy health check, even after the symlink has swapped. It adds a real-time dashboard with a team audit log, a deploy --stream terminal view, and CI/CD triggers via scoped tokens. It's self-hostable, and PHP Deployer users can import an existing deploy.php in one command.

Best for: Magento teams who want the full zero-downtime lifecycle on their own hosting, without a six-figure platform or a hand-built pipeline.
Watch for: it's a commercial product (flat monthly subscription, free trial), and it's Magento/Adobe Commerce-focused — not a general-purpose deployer.

At a glance

A simplified view — read the sections above for the nuance behind each cell.

Capability	Deployer	Capistrano	Adobe Cloud	Magefan	Orbit
Category	CLI tool	CLI tool	Managed PaaS	Magento module	Deploy agent
Runs on your servers	✓	✓	✗ (Adobe)	✓	✓
Atomic release swap	✓	✓	Managed	✓	✓
Handles DB-migration lock	✗	✗	Partial	✗	✓
Migration-lock forecast	✗	✗	✗	✗	✓
Skips unchanged builds	✗	✗	✗	✗	✓
Auto health rollback	✗	✗	✗	✗	✓
Dashboard + audit log	✗	✗	✓	✗	✓
CI/CD trigger	DIY	DIY	Native	Commands	Token
Magento-aware	Recipe	DIY	Native	Native	Native
Cost	Free OSS	Free OSS	Six-figure	$119–$303	Monthly sub

Which should you choose?

You want free and you'll own the pipeline: PHP Deployer. Add Magefan's module for low-cost, in-Magento zero-downtime builds.
You're already all-in on Capistrano across a mixed stack: extend Capistrano to Magento.
You're committed to the Adobe-managed platform: use the Cloud pipeline you're already paying for.
You want the full zero-downtime lifecycle on your own hosting — traffic hold, migration forecast, build-skip, auto-rollback, dashboard — without building or licensing a platform: that's the gap Orbit was built for.

There's no universally "best" tool here. There's the one that matches how you host, how much you want to build yourself, and what you're willing to spend.

Common questions

What is the best zero-downtime deployment tool for Magento 2?
There isn't a single best — it depends on your hosting and budget. PHP Deployer is the best free, self-hosted option if you'll maintain the pipeline. Adobe Commerce Cloud is the built-in choice if you're already on that platform. Orbit is the most complete purpose-built option for zero-downtime deploys on your own hosting (traffic hold, migration forecast, build-skip, auto-rollback). Magefan's module is a low-cost, in-Magento way to run zero-downtime builds — it builds in a temporary copy of your store and swaps it in.

Is PHP Deployer good for Magento?
Yes — it's free, mature, and has a Magento 2 recipe, and it handles atomic releases and rollback well. Its limits are the Magento-specific hard parts: it won't hold traffic during a long setup:upgrade, forecast the migration lock window, skip unchanged build phases, or roll back on a failed post-deploy health check. Those you either build yourself or get from a Magento-aware tool.

Do I need Adobe Commerce Cloud for zero-downtime deploys?
No. Adobe Commerce Cloud bundles a deploy pipeline, but you can get zero-downtime deploys on your own hosting with a deployer (Deployer, Capistrano) or a purpose-built agent (Orbit). Adobe Cloud only makes sense if you want the whole managed platform, not just the deploys.

How is Orbit different from PHP Deployer or Capistrano?
Deployer and Capistrano are generic orchestrators you script yourself; they nail the atomic release swap but stop there. Orbit is Magento-aware and covers the rest of the lifecycle: a traffic-holding cutover, a pre-deploy DB-migration block-window forecast, build-phase skipping, automatic health-checked rollback, a dashboard with audit logs, and CI triggers — and it can import your existing deploy.php.

Can you deploy Magento without a maintenance page?
Yes. The maintenance-page downtime comes from running setup:upgrade against the live site. You avoid it either by holding traffic during the migration (Orbit), by using an in-Magento module that keeps the store serving (Magefan), or by writing forward-compatible migrations so the old code tolerates the new schema. See our complete guide to zero-downtime Magento deployment for the mechanics.

The honest summary

If you want free and don't mind assembling the pipeline, Deployer is a great starting point. If you're on Adobe's platform, use what you're paying for. If you want to kill just the maintenance window cheaply, Magefan's module does exactly that. And if you want the full zero-downtime lifecycle for Magento on your own hosting — without building it yourself or buying a platform — that's the specific gap Orbit was built to fill.

Want to go deeper on the mechanics behind any of this? Read the complete guide to zero-downtime Magento deployment, how Orbit cuts deploy time to 75 seconds, or how we predict the migration block window before deploy.

Originally published on the Byte8 blog. See how Orbit deploys Magento with zero downtime →

The Scariest Part of a Magento Deploy Is the Database Migration. We Made It a Number.

Serhiy K — Wed, 12 Aug 2026 07:40:38 +0000

We tell people we deploy Magento at 2pm on a Tuesday. The most common reply isn't "no you don't" — it's "sure, but the database migration is the scary part." And they're right.

The cutover itself is trivial. Swapping a current symlink from one release directory to the next is atomic and instant; if it goes wrong you swap it back. Nobody loses sleep over the symlink. The part that actually makes a midday deploy frightening is setup:upgrade — and specifically not knowing, in advance, whether this release's schema change will finish in eight seconds or hold a lock on sales_order_item for four minutes. On a traditional pipeline you find that out live, in production, which is the worst possible place to learn it.

So we stopped guessing. Before setup:upgrade runs, Orbit now forecasts the block window and puts a number on the screen.

Why the block time is a coin flip

Since Magento 2.3, schema is declarative: each module ships an etc/db_schema.xml describing the tables it wants, and setup:upgrade diffs the declared state against the live database and emits the DDL to close the gap. That's a genuine improvement over hand-written InstallSchema scripts — but it hides the one thing you care about operationally, which is how long the resulting ALTER will block writes.

On MySQL 8 that answer swings enormously depending on the change:

Adding a column at the end of a table is instant — a metadata-only change, free regardless of table size.
Adding an index runs online — writes keep flowing, and the cost scales with row count.
Changing a column type forces a blocking table copy — MySQL rebuilds the whole table, and on a multi-million-row sales_* table that's minutes of held locks.

Same one-line diff in db_schema.xml. Wildly different consequences. And nothing in the standard Magento tooling tells you which one you're about to trigger until you're already triggering it.

The insight: everything you need to predict it is already sitting there

The forecast doesn't require a staging replay or a dry run. Three inputs that already exist on the box are enough:

The old release's declarative schema and the new release's — merge every module's db_schema.xml in each release tree exactly the way Magento does, then diff the two merged states.
MySQL 8's online-DDL rules — a well-documented matrix mapping each kind of change to instant / online / blocking.
Live table statistics — row counts straight from information_schema.tables, to turn "online index on a big table" into an actual number of seconds.

Put those together and the scariest unknown in Magento ops becomes arithmetic.

How Orbit forecasts the window

During the deploy, before it runs setup:upgrade, Orbit builds the merged declarative schema for both the outgoing and incoming release, diffs them, and classifies every change against the online-DDL matrix:

change in db_schema.xml            class       cost model
--------------------------------   ---------   ----------------------------
new / dropped table                metadata    ~instant
add column (tail)                  instant     ~instant, any table size
drop index / drop constraint       metadata    ~instant
add index / add constraint         online      ~ rows / 100k  (writes flow)
drop column                        online      ~ rows / 100k
modify column type                 blocking    ~ rows / 50k   (table rebuild)

Each online/blocking change is sized against the live row count for its table, the per-change estimates are summed, a little fixed overhead for Magento's own bootstrap is added, and the result is a single predicted hold in seconds. It reads like this in the deploy log:

→ "1 online index on sales_order_item (2.1M rows), ~12s. Within budget."

If it can't read a table's row count, it falls back to a conservative default and lowers its own confidence — reported honestly as high / medium / low rather than hidden. An arbitrary PHP data patch in Setup/Patch/Data can't be statically costed at all, so its presence pulls confidence down and says so. This is a forecast, and it's labelled like one.

What it does with the number

Two things, and it's worth being precise about the boundary between them.

It tells you before you commit. The prediction is advisory. It's written to the deploy record and surfaced in the log, and if the forecast exceeds the hold budget you set for that environment, Orbit warns you up front — "predicted hold ~90s exceeds the 25s budget; parked visitors will degrade to a waiting page." Whether to proceed now, or reschedule a genuinely long migration into a planned window, stays a human decision. Orbit's job is to make sure that decision is informed, not to quietly make it for you.

It makes the short windows a non-event. For environments that opt in, a bounded, fail-open traffic hold runs across the migration. It's a small buffer in front of the app that, for the few seconds the schema change needs, parks transactional requests — checkout, cart, customer actions — holding the connection open and replaying it against the app the instant the window clears. (Clients that give up are never replayed, so there are no double orders.) Everything else gets a lightweight waiting page with a live countdown driven by that same forecast, and anonymous browsing is served from cache. It's deliberately fail-open: if the buffer can't start for any reason, the deploy simply proceeds rather than blocking. A twelve-second online index becomes twelve seconds of "one moment" for a handful of in-flight checkouts — not a burst of 503s, and not a maintenance banner for everyone.

The two systems are independent by design. The forecast informs you and drives the countdown; the hold protects in-flight requests. Neither one silently decides to skip or defer your migration.

What it does not do

It doesn't replay your migration on a copy of production, so it won't catch a pathological trigger or a data patch that does something expensive in PHP — those show up as lowered confidence, not a precise number. It doesn't turn a four-minute table rebuild into a fast one; physics still applies. What it removes is the surprise. A blocking MODIFY COLUMN on a huge table is still slow — but now you know that at 1:55pm, before you click deploy, instead of at 2:03pm with the phones ringing.

The whole game

The reason "deploy at 2pm on a Tuesday" sounds reckless is that the DB migration has always been an unbounded unknown. Turn that unknown into a number on a screen — before anyone clicks Deploy — and the fear goes with it. That's the entire point: not bravado, just refusing to find out the hard way.

Originally published on the Byte8 blog. See how Orbit deploys Magento with zero downtime →