Unhazzle is a European managed application platform: we deploy and operate your containerized application on European cloud providers (Hetzner and Scaleway today, OVH next), with AI agents built into the platform core. Production carried for you, decisions brought to you, and a written record of what the platform did. We're pre-launch, building with design partners.

Yes. A European field is forming, and Unhazzle is part of it: push-to-deploy simplicity on European infrastructure, with two additions that matter to EU B2B teams. Production is operated for you around the clock, and the platform writes down what it did, so 'where does our data live?' always has a current, factual answer. If production keeps eating your roadmap, the platform you migrate to matters as much as the migration.

A git repository or an OCI image, and your intent: what the service is, what it needs, roughly how big. The platform proposes the rest: sizing, dependencies like Postgres or a cache, service-to-service wiring, and placement inside the EU. You review the proposal, approve it, and ship. From then on it's push-to-deploy, with rollbacks handled.

In EU regions, on European-headquartered providers (Hetzner and Scaleway today, OVH next). Each service is placed for you based on where your users are and the compliance you need, or you choose the placement yourself, always within the EU. Either way the placement is recorded, so 'where is our data?' has a specific, current answer instead of a marketing one.

The platform notices from the errors, not from a complaint. At the infrastructure level we're accountable: if the fix is an action you've already approved, like rolling back a bad deploy, it acts, verifies recovery, and writes the account as it happens; anything past your bounds pages our engineers, not yours. When the cause is at the application level, a slow query, a degrading release, we help with the triage: the account tells you what it saw and where it points, but the fix is ultimately yours. The responsibility matrix on the platform page draws the whole line.

Less than the demos imply, on purpose. The agents are built into the platform core: they read logs, events, deploy history and configuration; explain failures in plain language; and draft fixes, capacity changes and placement proposals. That surface is next on the build list, and it ships read-only: a human approves anything that touches a live system. The platform page lists what runs today and what doesn't.

Only what you've granted, action by action. You might allow rolling back a bad deploy, or scaling within a monthly budget; each grant is explicit, recorded, and revocable any time. Everything else arrives as a draft that asks first: new subprocessors and database migrations always do, by default. The dials start at read-only, and acting while you're away is the last capability to earn, not the first.

The agents work on operational telemetry: logs, events, deploy history, configuration, cost. They don't read the data your application processes. Code and infrastructure changes only ever arrive as drafts for your review; nothing lands in your repository without your approval, and production changes follow the autonomy you've set.

You'll see exactly what it did: every action writes its trigger, its steps and its result to the record as it happens. Actions eligible for autonomy are picked to be reversible, like rolling back to a known-good release; irreversible ones always ask first. And if you disagree with a call, you pull the grant back: autonomy is per action, and revoking it is one click, not a support ticket.

No: needing to is the problem we remove. Your services are containers; you describe intent, review what the platform proposes, and approve decisions. Kubernetes, scaling, backups, certificates and the 3am page are our side of the line, on standard building blocks underneath, so leaving is a migration, not a rewrite.

It settles less than it seems. An EU region keeps data in Europe physically, but jurisdiction follows the company, not the datacenter: under the US CLOUD Act, a US-headquartered provider can be compelled to produce data it holds regardless of where the server sits. Your customer's lawyer knows this; it's why they ask who operates the infrastructure, not just where it is. Our stack is European companies operating European infrastructure, so that answer holds.

The infrastructure-shaped part, and we're specific about it. Most of a compliance framework is paperwork that stays on your side: policies, risk assessments, training, auditor management. Roughly a fifth of the controls in a typical framework are about infrastructure: residency, access, encryption, backups, logging. We run that part, and the platform's record answers for it factually. The rest is yours, and a vendor who implies otherwise is selling certainty they don't have.

None yet, and we won't imply otherwise. The providers we run on publish their own certifications, ISO 27001 among them, and our own ISO 27001 path is on the roadmap. We publish where we are rather than renting credibility from a badge wall: when a certificate exists you'll see the certificate, and until then you'll see the record.

Not self-serve: we haven't launched. The platform runs, with our own product as its first workload, and we're working with a small number of design partners: what they tell us decides what gets built first. The offer: describe your stack, the services, the providers, what keeps breaking. We'll map how we'd run it hands free: what the platform carries, what stays yours, and what it would cost. No pitch attached.