Stop sharing one way in.
Voodu ships anonymous: whoever reaches the port is the operator, and a VPN or access proxy in front of it is what does the authenticating. That is a real deployment shape and it stays supported. It stops being enough the second person joins — because “who restarted that pod” has no answer when everyone is the same account.
Free for one app · from $9/month for more · nothing moves until you confirm
Anonymous mode is not a bypass. That matters.
With no sign-in configured, Voodu does not skip authorization — it provisions one real local operator, with a real account, org and owner membership. Every permission check runs down the same single path it always runs down; there simply happens to be one membership to find. There is no second code path to get wrong later.
One command, no configuration
A single docker run and a volume. No identity provider to register, no keys to rotate, no login screen between an operator and an incident.
One operator, owning one org
The Free Tier account. It owns the workspace, registers servers, and holds the controller tokens — exactly like a signed-in owner would.
Whoever reaches the port is that owner
And an owner can reveal a controller token, which is not a metric — it is deploy, exec and logs on the box. Expose port 3000 without a perimeter in front and you are not leaking a chart, you are handing over the infrastructure.
The dashboard says this out loud. When it is running anonymous and a request arrives from an address that is not private, it shows a standing warning rather than waiting for someone to read the docs. Put Twingate, Tailscale, Cloudflare Access or your own VPN in front, or give people real identities — below.
People arrive as themselves.
Clowk is the identity layer. Voodu does not implement passwords, sessions or provider integrations — it mirrors a verified subject onto a local user and then answers the only question it cares about: what may this person do here.
Google, Apple, GitHub and X
People sign in with an account they already have and already protect with their own second factor. Nothing new to issue, nothing new to reset.
Removing someone takes effect immediately
Access is read from the database on every request, so a removed membership is refused on the very next click — not at the next session expiry.
And their session ends too
With a secret key configured, Voodu also asks Clowk to end that person's sessions. Best effort by design: a broker outage must never stop an admin from removing somebody.
Invitations instead of a shared door
Bring a teammate in with the role they need. An invitation nobody has accepted grants nothing — being asked is not the same as being inside.
Actions have an author
Who registered that server, who rotated that token, who turned sign-in on. On a shared login all of it reads as “the operator”.
Per-server access, not all-or-nothing
A member can be granted the two servers they are on call for, rather than the whole fleet, and the org-wide surfaces stay with the people who run the org.
Nothing moves until you have actually signed in.
This is the step that goes wrong in every product that does it naively. Anonymous mode runs as one local operator; a first Clowk sign-in creates a user keyed on the identity provider's subject. Do the handover eagerly and that first real sign-in produces a brand-new user with no membership — while every server, every token and every dashboard stays behind an account nobody can reach any more.
You record the claim
Paste the publishable key and the address that will own the workspace. This writes down who MAY claim it. It does not move anything.
Sign-in turns on
The next request asks you to authenticate. Everything you registered is still there, still owned by the anonymous operator.
You sign in as that person
Clowk verifies you. Because the address matches the one recorded, the dashboard offers you the workspace and tells you exactly what it contains.
You confirm, and it is yours
Orgs, servers, tokens and history transfer to your identity in one step. Sign-in is now required for everyone.
You cannot lock yourself out. Environment variables always beat what is stored in the database, so a wrong publishable key is recoverable from the host: restart with CLOWK_ENABLED=0 and you are back in as the local operator, with everything where you left it.
Three of them, and each one is a sentence.
Roles are ordered, and every capability names the lowest role that holds it — so a permission check is a comparison rather than a list of exceptions that drifts. Anything not listed is denied.
The same table decides what the interface draws. A control somebody may not use is not rendered — and the endpoint behind it refuses the request anyway, because a hidden button is decoration, not authorization.
From the screen, or from your environment.
The screen above is the right route for an installation that already exists and already has servers in it. For a box you rebuild from scratch, configure it the same way you configure everything else.
docker run -d --name voodu-webui \
-p 3000:3000 \
-v voodu:/rails/storage \
-e CLOWK_ENABLED=1 \
-e CLOWK_PUBLISHABLE_KEY=pk_live_... \
ghcr.io/thadeu/voodu-webuiservices:
webui:
image: ghcr.io/thadeu/voodu-webui
restart: unless-stopped
ports:
- "3000:3000"
volumes:
- voodu:/rails/storage
environment:
CLOWK_ENABLED: "1"
CLOWK_PUBLISHABLE_KEY: pk_live_...
# Optional. Your own auth domain, if you run one.
CLOWK_SUBDOMAIN_URL: https://auth.company.com
# Optional. Lets Voodu end a removed person's Clowk
# sessions as well as denying them here.
CLOWK_SECRET_KEY: sk_live_...
volumes:
voodu:A misconfigured box refuses to boot
Asking for sign-in in production without a publishable key does not silently fall back to letting everyone in. It stops, and says which variable is missing.
An upgrade never removes authentication
If a publishable key is set, sign-in stays on whether or not the flag is. Losing your login to a routine image bump is not a failure mode worth allowing.
The flag is also the escape hatch
CLOWK_ENABLED=0 returns the installation to anonymous, with the workspace intact. Make sure the perimeter is back in front of it first.
Before you turn it on.
Do we have to use Clowk?
No. Anonymous behind your own perimeter is a supported, complete deployment — it is the default. Clowk is what you reach for when the perimeter can tell you someone is an employee but not which one.
What does it cost?
Creating an account is free, and one app is free — which is what a single Voodu installation is. From $9 a month if you need more than that.
Does Voodu see our passwords?
It never sees them. Voodu verifies a signed token and mirrors the subject onto a local user row. Credentials, second factors and provider integrations stay with Clowk.
What happens to what we already registered?
It transfers to you in one confirmed step, after you have proven you can sign in. Until then it stays exactly where it is — that ordering is the whole design.
Can we turn it off again?
Yes, from the screen while you are still signed in, or from the host with an environment variable. Nothing is deleted either way.
Is this an Enterprise feature?
Sign-in itself is not gated. The free tier caps how many people you can invite, so identity for a team pairs with an Enterprise licence in practice.
Give the second person their own login.
Free to create an account and free for one app. Paste the key into your dashboard when you are ready — nothing moves until you sign in and confirm.