Do we need a separate installation for each event?

No. One deployment holds as many events as you need. Each event is its own workspace with its own team, templates and settings, and the separation between them is enforced in the data layer by a Prisma client extension rather than by the interface hiding things.

Can each event have its own web domain?

No, and it is worth being precise about this. Each event gets its own web address, derived from its short name and checked for availability when you set it up, and its own sender identity for email: the name it sends under, the from-address and the reply-to. The domain itself belongs to the deployment.

Does WhatsApp still work if we host Conclave ourselves?

Yes, through Meta using the templates approved for your sender. That leg of the path belongs to Meta and cannot be moved into your datacentre. Everything else can, and email can be delivered by a relay you run.

What happens at check-in if the venue network drops?

Scans are held on the device and synced when the connection returns, so the queue keeps moving. Check-in runs in a browser on any phone or tablet, so a volunteer arriving with an unexpected device is still a working scanner.

Who inside our organisation can see participants’ contact details?

Access is granted per event, by role: check-in operator, registration manager, viewer, event admin. Roles without the PII permission see registrations with the contact details masked, so a volunteer on the door does not get the delegate list.

Can we get our data out again?

Yes. The registration list exports, reports export, and if you are hosting it the database is yours — a dump needs nobody’s permission and no ticket.

Data residency

The whole stack can run inside your own country

Conclave ships as a Docker Compose stack: the application, a Postgres database, Redis and a worker. Put those four containers on a machine in Chennai, Riyadh or Dublin and that is where your participants’ data lives. Nothing in the design requires it to come to us.

What actually ships

Four containers and one Compose file. There is no hosted component you have to keep talking to, and no piece that only works in our account.

The application
Next.js
What organisers and delegates actually see: the registration form, the wizard, the lists, the check-in screen.
The database
Postgres
Every registration, approval, entry pass, message record and audit entry. For a residency question, this container is the answer — its volume is the data.
The queue
Redis
Work waiting to happen, plus short-lived state. Treat it as in scope: a job waiting to send a confirmation is holding a name and an address while it waits.
The worker
Background jobs
Sends the mail, renders the entry passes, runs the reminders that are scheduled against the event date.

Where the data physically sits

Three shapes this takes in practice. None of them is a special edition of the product; they are the same Compose file on different machines.

An Indian professional association

The requirement usually arrives as a line in your own bye-laws or in a clause from the institution hosting the conference: member data stays in India.

Put the four containers on a machine in an Indian region of whichever cloud you already use, or in the rack in your own office. Member names, phone numbers and membership numbers sit in a Postgres volume on that machine. Whoever holds the machine holds the data, and that is your IT team.

A Gulf government body

Public bodies here are often required to run inside a government cloud with tightly controlled egress, and to name every external party that touches citizen data.

The stack runs there. Email can leave through an internal relay, so the list of external parties can be empty. The honest exception is WhatsApp: it is delivered by Meta and cannot be moved inside a private network, so it is either an accepted external party or a channel you do not switch on.

A European organisation

Two different questions get asked together — where does the data sit, and who else can reach it. Residency is the easy half.

Run it in the region you have chosen, with the database and its backups in the same region. Self-hosting mostly answers the second question: the parties who can reach participant data become you, your hosting provider, and whoever you picked to deliver mail. That is a short list to write down, and you wrote it.

What crosses the boundary

The interesting rows are the last three. Everything a delegate typed stays on your machine; what leaves is what you asked to be delivered somewhere.

Where each kind of data lives in a self-hosted deployment, and what leaves your network
Data	Where it lives	What leaves your boundary
Registrations, approvals, entry passes, audit log	Your Postgres volume	Nothing
Queued jobs and short-lived state	Your Redis	Nothing
Entry pass images and exports	Generated by your worker	Nothing, until you send or download one
Email	Whichever mail provider you configure	The message and the recipient address. Point it at an internal SMTP relay and even that stays inside.
WhatsApp	Meta's API, using your approved sender	The recipient number and the template values. This one cannot be brought in-house — see below.
Us	A deployment we do not operate	Nothing. If you want our help you grant access deliberately, and revoke it after

If your security review needs the exact list of outbound connections the stack makes, ask for it and check it against your own firewall logs rather than against our word. Ask us.

What you take on when you host it

Control is not free, and this is the invoice. None of it is difficult for a team that already runs servers — but somebody has to own each line, by name, before the first event rather than during it.

Backups, and restoring from one: Snapshotting the Postgres volume is your job, and so is restoring it somewhere once to prove it works. An untested backup is a rumour.
TLS: Issuing and renewing the certificate for whatever hostname you serve it on. An expired certificate on the morning of an event is a closed door.
Upgrades: New versions do not apply themselves. Somebody pulls the images and runs the migrations, on a date you choose — which is the trade you made for control.
Watching it: Conclave reports its own health — database, queue, workers — but that is a report, not an alarm. Something of yours has to read it and wake a person.
Secrets: The database password, the key that signs entry passes, mail and WhatsApp credentials. You hold them, you rotate them, and nobody can email them back to you.
Capacity: Nine hundred people scanning between 08:45 and 09:15 is a spike, not a load average. Sizing the machine for the door, not for the average day, is yours.

What we are not claiming

No SOC 2. No ISO 27001. Not “GDPR certified” — there is no such certificate, and anyone selling you event software on that phrase has told you something about themselves. No audit of any kind has been carried out here, and we are not going to imply one with a badge.

What self-hosting gives you is not a certificate. It is a control: you choose the jurisdiction, you hold the credentials, you can walk into the room where the machine is. For a lot of security reviews that is worth more than a PDF about somebody else’s datacentre.

If your process needs the paper rather than the control, tell us in week one. We would rather be ruled out early than waste a procurement cycle.

Questions this page usually raises

Do we need a separate installation for each event?: No. One deployment holds as many events as you need. Each event is its own workspace with its own team, templates and settings, and the separation between them is enforced in the data layer by a Prisma client extension rather than by the interface hiding things.
Can each event have its own web domain?: No, and it is worth being precise about this. Each event gets its own web address, derived from its short name and checked for availability when you set it up, and its own sender identity for email: the name it sends under, the from-address and the reply-to. The domain itself belongs to the deployment.
Does WhatsApp still work if we host Conclave ourselves?: Yes, through Meta using the templates approved for your sender. That leg of the path belongs to Meta and cannot be moved into your datacentre. Everything else can, and email can be delivered by a relay you run.
What happens at check-in if the venue network drops?: Scans are held on the device and synced when the connection returns, so the queue keeps moving. Check-in runs in a browser on any phone or tablet, so a volunteer arriving with an unexpected device is still a working scanner.
Who inside our organisation can see participants’ contact details?: Access is granted per event, by role: check-in operator, registration manager, viewer, event admin. Roles without the PII permission see registrations with the contact details masked, so a volunteer on the door does not get the delegate list.
Can we get our data out again?: Yes. The registration list exports, reports export, and if you are hosting it the database is yours — a dump needs nobody’s permission and no ticket.

Still unanswered? Write to us or open the demo and look at the thing itself.