Why we moved our infrastructure

Between 24 July and 6 August 2026 we had no access to the account under which our servers ran. For two weeks we could not manage our own infrastructure, could not scale it, could not move it, and could not add new projects to it.

We resolved that by moving everything. This page describes what happened, what it cost us, and what we changed — because you are entitled to that information if you are considering trusting us with your work.

What happened

Our servers were hosted with Hetzner Online GmbH. On 24 July, access to our management account was blocked. We were informed that unauthorised access to the account was suspected.

We asked what that suspicion was based on, and for access to the log records supporting it. That substantiation was never provided.

We completed the identity verification that was requested. It was finalised and accepted. Access was still not restored.

During that period our case was spread across four separate tickets, answered by different staff members who were unaware of what the others had already said. Our formal complaint was not escalated, and to this day it has not been answered on any substantive point.

On 6 August the account was closed at our request.

What it cost us

Several of our platforms ran on those servers. For two weeks we could change nothing about them: no maintenance, no expansion, and no new projects for clients.

That last point went beyond inconvenience — it affected what we could deliver. We lost clients during that period.

What we changed

All platforms have been moved to our own servers within the European Union. Each platform now runs on its own machine, under our own control:

• direct access, with no intermediary able to lock us out
• daily backups, stored off the machine
• separated environments — a problem on one platform does not reach another
• our own key management, one key per machine

Our hosting service, Technovize Cloud, runs on that same infrastructure. What we deliver to our customers runs on what we use ourselves.

What this means for your project

We no longer place client projects with this provider. If you specifically want to run there, you can — but with your own account and under your own management. We will not take that management on.

The reason is simple: whatever we deliver to you, we must also be able to restore ourselves. For two weeks, there, we could not.

Their response

On 12 August 2026, Hetzner responded publicly to our review:

“To maintain the confidentiality of this matter, we can’t publicly disclose any information regarding this specific case. For security reasons, we generally take the necessary measures whenever irregularities are detected during the login.”

We do not dispute that action was taken on a login signal. That can be legitimate, and we have never contested it.

What this response does not answer: what that signal consisted of, why the substantiation was never provided, why access was not restored after an accepted identity verification, why one case ran across four tickets, and why a formal complaint was not escalated. Confidentiality stands in the way of none of those answers; not one of them requires disclosing any account detail.

Our assessment, and the nuance in it

We have no complaint about the servers themselves. They were technically sound, and they probably still are.

Our complaint concerns the handling of this incident, and in our assessment that fell short on every point that matters: speed, competence, and willingness to take responsibility. Imposing a block on the basis of a suspicion can be legitimate. Never substantiating that suspicion, accepting the verification without restoring access, and answering a formal complaint twice without addressing a single substantive point — that is something else.

We have documented this incident in full internally. If you have questions about anything on this page, we will gladly answer them.