Data residency
Conclave is a SaaS product: ZEBIQ TECHNOLOGY LLP hosts it and runs it for you, and that is how most organisations use it.
When delegate data has to stay inside one jurisdiction, the same software 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. The rest of this page is about that option.
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.
Next.js
What organisers and delegates actually see: the registration form, the wizard, the lists, the check-in screen.
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.
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.
Background jobs
Sends the mail, renders the entry passes, runs the reminders that are scheduled against the event date.
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.
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.
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.
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.
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.
| 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 |
| Whichever mail provider you configure | The message and the recipient address. Point it at an internal SMTP relay and even that stays inside. | |
| 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.
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.
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.
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.
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.
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.
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.
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.
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.