The website in a suitcase: a safety net for everything we build

It began with an uncomfortable finding: small defects showed up on the live estate agent website — but in the development system they could not be reproduced. The content they become visible on was simply missing there. We faced a choice: operate on the open heart of the live website, or poke around blindly in an empty development system. Neither is a good idea.

The website in a suitcase

The answer, as of today, is a section of its own in the administration: backups. One click packs a complete website into a suitcase — every page, every menu, every module, the design and its template, the blog with all its images, the media library at original size and even the visitor accounts along with their credentials. Nothing is left behind.

The suitcase can be unpacked at its destination in two ways: as a new website beside the existing ones — for which the administration asks for a new address, so that the test system never accidentally answers under the real domain — or over an existing website, which is then replaced completely but keeps its address. And because a suitcase is made for travelling, you can download it, carry it to another system and upload it there. That is exactly how the live state reached the development system today — and the defects were visible for the first time in a place where they can be examined without risk.

The lock on the suitcase

A suitcase like that holds everything, including the visitors' credentials. That is why it gets a lock on request: a password that encrypts the whole content. The password is stored nowhere — whoever forgets it holds a suitcase nobody can open again. No back door, and that is deliberate. A wrong password, by the way, is recognised before a single row is imported: there are no half-unpacked suitcases.

The future mattered to us just as much: a backup that becomes unreadable after the next software update is no backup. Two guards therefore watch in every test run from now on — one raises the alarm if a future addition forgets to put its data into the suitcase; the other opens a frozen reference backup from today on every run. If that one stays readable, they all do.

The suitcase was too heavy

The first real test brought disillusion: 1.7 gigabytes of website, and in the middle of the upload the transfer broke off — after exactly 100 seconds. A time limit from the factory settings, meant for short requests, not for removal cases. On top of that the interface froze during the transfer.

Both are fixed: transfers now run in the background, a dialog shows the progress in percent, and instead of a rigid time limit there is a cancel button — the human decides, not the stopwatch. Along the way it turned out that the transfer was working with far too small parcels; with a proper buffer size the suitcase now travels considerably faster as well.

The bug that made itself invisible

The finest find of the day came from the clean-up afterwards: a restored website could not be deleted — “access denied”, without any explanation. The hunt led to data rows that a background service had created long ago without giving them an owner. Ownerless rows are doubly treacherous in our tenant model: you cannot see them, but they block. The service now always enters the owner, a start-up run of the server adopts the existing orphans — and the access denial writes a clear line into the log from now on, naming the culprit. The next bug of this kind will not be able to hide.

The balance

Planned in the morning, built in the afternoon, through the complete test track in the evening: over 3,500 tests green, zero findings in the code analysis, test coverage held. The safety net is up — and the first suitcase has already travelled.

For you as a future user this means: your website is not a one-way street. It can be secured, moved, handed on and, in an emergency, restored — completely, encrypted, and still readable long after the software has grown on.