~/managed-wordpress · for EU agencies

Your client’s site changes only when the clone is healthy.

For agencies who cannot afford a white screen after a plugin update. Every site in one place, on EU infrastructure.

Private beta · self-serve signup is not open yet

CMS
✓No visit metering✓Tested before live✓WAF on every site✓EU-only data

Solo, not an agency? TivadarCMS for freelancers →

Managing client WordPress at scale shouldn’t mean this.

You’re holding together a dozen dashboards, praying a plugin update doesn’t take a client offline, and finding out about a breach from the client instead of from your tools.

  • !

    Five tools, no single view.

    cPanel here, a security plugin there, backups somewhere else. No one place that says what’s healthy and what’s on fire.

  • ×

    One bad deploy, one client down.

    Updates go straight to production and hope for the best. The 2am call is always yours.

  • ▲

    You hear about breaches from clients.

    No defense by default, no alerting you trust, so the first sign of trouble is an angry email.

  • #

    Every new client is more chaos.

    Another login, another dashboard, another thing that breaks at the worst time.

Why your client sites stay up, and stay yours.

[isolation]

One client’s breach can’t touch another’s site.

Every tenant runs in its own isolated Kubernetes namespace: own pods, own database. No shared runtime, no noisy neighbours.

[tested-before-live]

No untested change reaches a live client site.

Every update runs on a production clone first, and reaches the live site only once that clone comes up healthy, so a broken update surfaces on a throwaway copy.

[sentinel-waf]

Defended from the moment it goes live.

Tivadar Sentinel, a production-grade WAF and edge, sits in front of every site by default. Not a paid add-on, not a later upgrade.

[alerts]

You hear about a blocked attack from Sentinel.

Sentinel raises the alert when it blocks something, and every backup run is a tracked job with a result you can read. Both are recorded against the site they belong to, in the dashboard that hosts it rather than in a separate provider console.

[typical-shared-hosting]

One runtime, nothing between the sites

Two client sites inside a single shared runtime, with a breach spreading from one to the other because nothing separates them.one shared runtimeSite ASite Ba breach on one reaches the other
[isolation]

One namespace per account, a boundary per site

Two client sites of one business account inside a single tenant namespace, each with its own pods and database, separated by a per-site network policy that blocks traffic between them.tenant namespace (one business account)Site ASite Bown pods · own databasenetwork policy blocks the reach

See the whole fleet, then one site, deep.

One dashboard that answers “is everything healthy?” at a glance, and a cockpit per site when you need to go deeper.

tivadar / fleet · demo
client-a.exampleonline142ms
client-b.exampleonline98ms
client-c.exampleonline121ms
client-d.exampleonline110ms
4 sites, all healthy · WAF active, 0 incidents
Site Manager · fleet overview
tivadar / client-a cockpit · demo
Traffic48 req/s
apphealthy
databasehealthy
cachehealthy
firewallhealthy
Threats blocked · 24h37
demo data: site names, latency, traffic and threat counts are illustrative
Site Manager · site cockpit
~/what-adopting-this-costs

What moving one client site actually involves.

Three steps, and you drive all of them, once the Agent ships. It is still being built and is not on WordPress.org yet, so this is the path as designed, not one you can walk today. The site keeps serving from where it serves today; the copy runs beside it on the real platform, with real isolation and real defenses, so you can look at it before anything in production changes. Nothing is switched over until you say so, and nothing about the live site is touched to get there.

  1. Install the free Agent
    The Agent will be a free plugin on WordPress.org, and the install will be yours to run, not something done to your site.
  2. Open a Cloud Connection
    The Agent links the site to your operator account. It’s now a Connected Site.
  3. We clone it onto the platform
    A staging copy runs on the real infrastructure. See it before you commit.
tivadar / clone & verify · demo

A clone needs the Agent on the source site and a DPA (AV-Vertrag) to process client data. See how Cloud Connection works →

Talk to an engineer

You talk to the engineer who built it.

No ticket queue, no first-line script. When something matters, you reach the person who architected the platform, and who answers. I’m Dániel Belső: 12 years as a developer, including PHP work at LastPass on problems that reached into the platform, and I built TivadarCMS end to end.

I run 7 WordPress sites and 3 Next.js apps in production on TivadarCMS myself. The first of them has run since September 2025, 12 months ago. They are my own work, not a client’s: there are no customers on the platform yet, and this page does not pretend otherwise. The platform it is selling you is the one already carrying mine.

  • →Direct line to the architect, not a support tier.
  • →Built and run by one accountable engineer, not a black box.
  • →Decisions explained, not hidden behind a dashboard.
Talk to an engineer
Dániel Belső, founder and engineer
Dániel Belső
Founder & Engineer

No metering. No overage surprises. No “unlimited” BS.

You price your client retainers on certainty. So we price the same way: predictable per-site and per-pool, with the resources you bought. Traffic spikes don’t trigger a surprise invoice, and “unlimited” claims you can’t trust aren’t on the menu.

  • No visit metering, no traffic billing.
  • Dedicated CPU/RAM per plan, not oversold shared hosting.
  • Scale within your pool automatically; expand only with your explicit go-ahead.

From €49/mo

Private beta · self-serve signup is not open yet

See plans
~/where-the-data-lives

100% EU infrastructure. GDPR by architecture.

For your EU clients, data residency isn’t a checkbox bolted on later; it’s where the platform runs. Every workload sits on EU infrastructure (Hetzner), with no US subprocessor in the serving path. The one US recipient is a manual IP lookup an operator can run while investigating an incident, never automatic and never an email address, and it is listed on /trust. Compliance becomes a property of the architecture, not a promise.

✓100% EU infrastructure (Hetzner)✓Serving path: EU only✓DPA (AV-Vertrag) available✓Published subprocessor list

Straight answers.

Is this production-ready or still beta?
It is in a closed test period. I run my own sites in production on it (provisioned, defended and backed up by the platform itself), and the test is closed on purpose: a small first group I can stand behind is worth more than an open door I cannot. Self-serve signup is not open yet; access starts with a conversation.
What happens when a plugin update breaks a site?
It doesn’t reach production untested. Every change runs on a production clone and is promoted with zero downtime only once the clone comes up healthy, so a bad update surfaces on a throwaway copy, not on your client’s homepage.
Where does my data live?
100% EU infrastructure (Hetzner), with no US subprocessor in the serving path; the one US recipient is a manual IP lookup during an incident, listed on /trust. Compliance is a property of the architecture, not a checkbox bolted on later.
Is this an AI platform? Does my client’s data reach a US AI vendor?
No. There is no US subprocessor in the serving path, no AI vendor is engaged on your behalf, and nothing leaves unless you connect it yourself. Separately, you will be able to open an MCP endpoint against your own data, with your own client, at your own initiative, in two planned modes: full access, or a scope you configure. Neither is built yet. If you open one, the vendor is yours, the contract is yours and the key is yours; we are not engaging an AI provider on your behalf and have no part in what you connect.
Do you meter traffic, or bill for it?
No. Pricing is predictable per-site and per-pool, with the resources you bought. A traffic spike never triggers a surprise invoice, and there are no “unlimited” claims you can’t trust. Sites are the one thing that can add to a bill: past the number your plan includes, you buy another at the Solo price, shown before you confirm.
Can I move existing client sites in?
Yes. What it takes depends on the site: its size, its plugins and how it is hosted today. So it starts as a conversation rather than a form you fill in. A WordPress plugin, the Tivadar Agent, is in development and is what will make it self-serve later; it is not finished, and I am not going to put a date on it here.Talk to an engineer
Who do I talk to when something’s wrong?
The engineer who built the platform: me, directly. No ticket queue, no first-line script, no black box.

Talk to an engineer.

One person reads these: the engineer who built the platform. Tell me what you run today and what is going wrong with it, and you get an answer rather than a sales sequence.

Fields marked * are required.

No newsletter, no sequence. This goes to one inbox.

~/waitlist

Join the waitlist.

Join the list and you get product updates while the platform is in a closed test: what shipped, what broke, what is next. Double opt-in; unsubscribe any time.

Fields marked * are required.

Product updates only. Unsubscribe from any email.

Rather talk first? Talk to an engineer, and the engineer who built the platform reads it.