Vefapp · Backups and monitoringAfritavakt · Tæknivakt

Backups that exist when it counts.

In short

Every night we back up the code and the database of every project we run. The backups are encrypted and stored in a datacentre in the Netherlands, and an immutable copy is replicated to Italy. Every morning our monitoring reads every project and tells us when a security flaw turns up in the software it depends on.

The numbers

03:00: Backups start every night, with retries at 04:00 and 05:00 if anything fails.
2 countries: Datacentres in the Netherlands and Italy, both inside the EEA.
35 days: For that long nobody can delete or change a backup, us included.
07:00: Monitoring checks every project each morning.

Backups

Your code and data, in two places.

Each project gets two backups: the full code repository with its entire history, and a complete copy of the database. Both take the same route.

01
Collected
At 03:00 we fetch the project's code, every branch and its full history, and take a consistent snapshot of the database.
02
Encrypted
The backup is encrypted before it leaves. The key that opens it is kept outside the system, so the server writing the backups cannot read them.
03
Netherlands
The backup is stored with Wasabi in a datacentre in the Netherlands and locked for 35 days. In that time nobody can delete it: not us, not Wasabi, and not anyone who got hold of our access keys.
04
Italy
An immutable copy is replicated on to a second datacentre in Italy. A failure, fire or flood at one site does not touch the other.

Verified, not just sent

Every backup is checked after upload. The code must pass git's own checksum, and the row count of every table is compared with the database it came from. A backup that fails the check raises an alert.

A watch that watches itself

At 09:00 a separate check asks whether every project has a fresh, verified backup. If one does not, we get an email, and it comes again every day until the problem is fixed.

Independent of hosting

The backups live with a different company from the one hosting the site and the database. If an account is closed or the hosting is attacked, the backups are still there.

Inside the EEA

Both datacentres are inside the EEA, so backups of personal data never leave the area covers.

Three layers

What each provider backs up, and what it does not

Our backups are not the only safeguard. and , which host the projects, have their own. They do different things, and it pays to know what each one covers.

01Vercel

Every version of the site kept

keeps every version of the site as a separate, immutable build. If a release causes trouble we move the site back to the previous one in seconds, without rebuilding anything. The ten most recent production versions and the one that is live are never deleted.

Keeps the code that runs, not the data. Vercel does not back up the database.

02Supabase

Daily database backups

, which hosts the database, takes its own daily backups on its paid plans and keeps them for 7 to 30 days depending on the plan. They let the database be restored to an earlier day.

Those backups sit with the same company as the database itself.

03Afritavakt

Our own copy, outside the hosting

Code and database, backed up every night, encrypted and locked in two countries. This is the copy that is left when the other two are not enough.

Independent of Vercel, Supabase and GitHub.

Monitoring

Security flaws get found, we upgrade.

Every web application is built on hundreds of open-source packages written by other people. Security flaws turn up in them regularly, and a site nobody updates becomes more exposed every month.

Every morning our monitoring reads the exact versions running in each project we maintain. It checks every package, including the ones other packages pull in, against the public database of known vulnerabilities that npm itself uses. When something new turns up we get a summary by email.

When serious flaws were found in , the framework most of our projects are built on, the monitoring showed at once which projects ran an exposed version and which release fixed them all.

Vulnerabilities

Known security flaws in any package, graded by severity. These are always reported.

New major versions

A new major version of a framework or key package calls for a planned upgrade, not a scramble. We hear about it straight away.

No noise

Small patches show on the dashboard but are not emailed. An email that arrives every day is an email nobody reads.

Questions

How often are backups taken?

Every night. The run starts at 03:00, and if anything fails it is retried at 04:00 and 05:00. At 09:00 we check that every project has a fresh, verified backup.

Can you read the backups?

The server that takes them cannot. Backups are encrypted to a public key, and the private key that opens them is kept outside the system. It is only brought out when data has to be restored.

What if Vercel or Supabase closes the account?

The backups still exist. They sit with a different company, on a different account, and from them we can stand the code and the database up somewhere new.

How far back do the backups go?

Each backup is locked for at least 35 days and older backups are kept after that. So the database can be recovered as it stood on any night since the project's backups began.

Are images and files backed up too?

The backups cover code and database. Files that users upload, such as images and documents, are stored separately and are not in Supabase's daily backups either. If a project holds files that must not be lost, we work out with you how best to back them up.