Security

Your Jitsi server runs in your AWS account, not ours. We hold an encrypted copy of the credentials you connect, use them to build and configure the server, and check its health afterwards. Your meetings, recordings and transcripts live entirely in your account and never pass through our infrastructure. When you destroy a server, the cloud resources go with it.

• Encrypted at rest. Access keys are stored with Fernet (AES-128 in CBC mode with an HMAC-SHA256 authentication tag), not in plain text. The encryption key lives in the server environment, not in the database, so a database dump alone does not reveal them.
• Least privilege is yours to set. Before anything is created, a preflight step checks the exact permissions the deployment needs and, if one is missing, shows you the precise IAM policy to paste. You can scope the key to only what the pipeline uses.
• Used, not resold. The credentials are used to run Terraform and to configure the instance over SSH. They are never shared, never used for anything outside your own deployments, and can be removed from Settings at any time.
• You can rotate or revoke in AWS. Because the server runs in your account, revoking a key in your own IAM console is the ultimate off switch, independent of us.

• Meeting media never touches us. Audio and video flow between participants and your own server. We are not in the call path and cannot see, store or record a meeting.
• Recordings and transcripts go to your S3. When you enable recording, the files are written to a bucket in your own AWS account. We hold the settings, not the files.
• What we do store: your account details, an encrypted copy of your cloud credentials, and metadata about your deployments and their status. Enough to build, operate and bill for the service, and no meeting content.
• New accounts use Google or a one-time email link. Browser session tokens are opaque, stored only as SHA-256 digests in Redis, and sent in HttpOnly cookies. API keys are also stored as SHA-256 digests.

The Terraform module opens four ports on your instance and nothing else. You can read the security-group rules in your own AWS console.

• 22/TCP: SSH, used to configure the server and closable afterwards from your own console.
• 80 and 443/TCP: the web app and HTTPS, with a Let's Encrypt certificate when you use a custom domain.
• 10000/UDP: the media port WebRTC uses for audio and video.

The pipeline validates your credentials, provisions with Terraform, configures the pinned Jitsi release with Ansible over SSH, waits for DNS and issues SSL, then health-checks the meeting service. Every step is visible to you as it happens, and a failure can be corrected and resumed rather than leaving half-built resources behind. The full sequence is on the How it works page.

With a JWT license on the deployment, you can require a signed token to enter a room, so only your own application can let people in. Without it, a room is reachable by anyone who knows its address, which is why a meeting booked through our API on a token-less server is given an unguessable random name rather than a readable one.

• Destroy removes what that deployment created: the instance, its IP, security group and any recording bucket the deployment made. It removes nothing else in your account, and the dialog lists every resource first.
• You can verify it in AWS. Because the resources are in your own account, you can confirm their removal directly, not just take our word for it.
• No lock-in. It is plain open-source Jitsi underneath. If you would rather take the server over yourself, you can.

We do not currently hold SOC 2, ISO 27001 or any other independent security certification, and this page does not claim one. What it describes are the controls that are actually implemented. The security of your AWS account, the IAM policy you attach to the key you connect, and the access controls on your own S3 buckets remain yours to manage, and are the right place to apply your organisation's own standards.

If you believe you have found a security issue, email admin@rexxulabs.com with enough detail to reproduce it. Please give us a reasonable chance to fix it before disclosing it publicly. We will acknowledge your report and keep you updated on the fix.