How it works
Last updated 4 August 2026
A deployment is a sequence of steps you can watch happen. This is that sequence, in order, including the one place it deliberately pauses and what happens when something goes wrong.
The deployment, step by step
Connect your AWS account
You add an access key once. It is encrypted at rest and reused on every deployment, so you never paste it again. Nothing is created at this point.
Preflight, before anything is built
We validate the credentials and check the exact IAM permissions the deployment needs. If one is missing, you get the precise policy to paste. No billable resource exists until these checks pass, so a wrong key costs you nothing.
Provision with Terraform
A security group with four ports, an EC2 instance, and a static Elastic IP are created in your account. Terraform tracks exactly what it made, which is what lets teardown later remove precisely that and nothing else.
Configure with Ansible
Once the instance answers over SSH, Ansible installs Docker and the pinned Jitsi Meet release, including web, Prosody, Jicofo and the video bridge. It also configures any licensed recording, transcription or token-secured room features. Configuration is idempotent, so a retry does not double anything.
DNS and SSL
If you use a custom domain, the pipeline pauses until your DNS record points at the new server, then requests a free Let's Encrypt certificate. DNS is the one step outside our control, so this is where a deployment waits rather than fails. Skip the domain and the server runs on its IP with a self-signed certificate.
Health check
Before we call it done, the meeting service is checked end to end. Only then does the deployment report complete and hand you a working URL.
When a step fails
A deployment can fail for ordinary reasons: a missing IAM permission, a DNS record that has not propagated, a wrong domain. When it does, the pipeline stops at the failed step rather than tearing everything down, tells you what went wrong, and lets you correct it and resume from where it stopped. A resume does not create a second instance, IP or bucket; it continues the one deployment. You watch all of this as a live log, and it survives a browser refresh.
Operating it afterwards
Once it is live, the same dashboard changes branding, turns recording or transcription on and off, resizes the server, and pauses it on a schedule so it is not billing overnight. Configuration changes are applied to the running server and reported when they land.
Removing it
Destroy removes exactly what the deployment created and lists every resource before it does. Because everything is in your own AWS account, you can confirm the removal directly in your console. There is no lock-in and no export process: it is plain open-source Jitsi underneath.
Where security fits
This page is about the sequence; the Security page covers how your credentials are encrypted, where your meeting data lives, and what is opened on the network.