Frequently Asked Questions
Everything you need to know about hubport.cloud.
What does MIT + Commons Clause mean?
The source code is publicly available and free to use for congregations. You can inspect, modify, and self-host it without restrictions. The Commons Clause simply means: you may not sell it or offer it as a paid service.
- ✓ View and inspect the source code
- ✓ Self-host for your congregation
- ✓ Modify the code for your own use
- ✓ Share modifications (non-commercial)
- ✓ Contribute improvements
- ✗ Sell the software
- ✗ Offer it as a paid hosted service
- ✗ Bundle into a commercial product
Do I need to sign up to use hubport.cloud?
No. hubport.cloud is free, source-available software. You can download the code from GitHub and run it on your own server with your own domain — no registration required.
Benefits of registering:
- ✓ Automatic Cloudflare Tunnel setup — secure subdomain with zero networking knowledge
- ✓ Congregation-to-congregation sharing — exchange territory data and public talks
- ✓ Update notifications — get notified about new versions and security fixes
- ✓ Community directory — other congregations can discover and connect with you
To self-host on your own domain, we recommend Cloudflare (free plan) for DNS, CDN, and DDoS protection:
- 1. Create a free Cloudflare account and add your domain
- 2. Install cloudflared on your server (one binary, no dependencies)
- 3. Create a Cloudflare Tunnel: cloudflared tunnel create my-hubport
- 4. Point your domain to the tunnel — Cloudflare handles HTTPS automatically
- 5. Run hubport.cloud with Docker Compose — done!
Cloudflare Free Plan is free and includes DNS, CDN, DDoS protection, and Tunnel — no credit card required.
Where can I get a server?
We've had great experience with Hostinger VPS — affordable, reliable, and no Linux experience needed. The setup wizard handles everything:
* We use affiliate links. If you purchase through these links, we receive a small commission at no extra cost to you. This helps support the project.
Can I run it on my own hardware?
Yes! hubport.cloud runs anywhere Docker is available. Choose what fits your congregation best:
A server from Hostinger, Hetzner, or similar. Always online, accessible from anywhere.
Run Docker on a NAS in the Kingdom Hall. Great if you already have one.
Any Linux computer with Docker. Even a Raspberry Pi 4 is enough.
Do I need a dedicated IP address or open ports?
No. hubport.cloud uses Cloudflare Tunnel to connect your server securely to the internet — without opening any ports or needing a static IP address.
How it works:
- ✓ A small program (cloudflared) runs on your server alongside hubport.cloud
- ✓ It creates an encrypted outbound connection to Cloudflare's network — no inbound ports needed
- ✓ Cloudflare handles HTTPS, DDoS protection, and routing to your subdomain (e.g., penzberg-north.hubport.cloud)
- ✓ Your server can be behind a home router, NAT, or firewall — it just needs internet access
- ✓ No port forwarding, no dynamic DNS, no dedicated IP required
Is my subdomain publicly accessible? Is that safe?
Yes, your subdomain (e.g., penzberg-north.hubport.cloud) is reachable from the public internet — just like any website. But this is intentional and secure:
No one can see any data without logging in. Keycloak enforces authentication on every request — there is no anonymous access.
Your bank's website is also publicly reachable. The security comes from the login, not from hiding the URL.
Cloudflare automatically blocks malicious traffic, bots, and DDoS attacks before they reach your server.
All traffic is encrypted with TLS. No one can eavesdrop on the data in transit.
Every user must set up a passkey or authenticator app on first login. This is enforced automatically — not optional. Even if someone knows a password, they can't log in without the second factor.
How does user login and security work?
Each congregation runs its own Keycloak identity server and HashiCorp Vault — directly on your server. No cloud dependency, no shared login system.
Your security stack:
Every user must register a passkey (fingerprint, Face ID, security key) or set up an authenticator app (TOTP) on first login. This is enforced automatically by the Security Wizard — no opt-out.
Industry-standard identity server. Manages all user accounts, passwords, and roles (elder, publisher, viewer). Combined with passkey-first authentication for phishing-proof security.
Stores encryption keys, database credentials, and API tokens. Sensitive data in the database is encrypted — only Vault can unlock it.
Elders see publisher records and can manage territories. Publishers see their own assignments. Viewers have read-only access. The tenant admin controls all roles.
How is my data encrypted?
Publisher names, emails, and phone numbers are encrypted with AES-256-GCM before they are written to the database. Even if someone gains direct access to the database, the data is unreadable without the encryption key stored in Vault.
When data is saved:
When data is read:
The encryption key never leaves Vault. Database backups contain only encrypted data. Even we (the platform) cannot decrypt your data — the key is on YOUR server.
Does hubport.cloud include internal messaging?
Yes. Every hub includes a built-in, self-hosted chat system powered by the Matrix protocol. Here's how it works and why it's secure:
How it works
- ● Matrix (Synapse) runs inside your Docker stack — on YOUR server
- ● Element Web provides the chat interface — integrated directly into the hub
- ● Single sign-on via Keycloak — same login as the hub, no separate password
- ● Channels auto-created for service groups, duty teams, and elder-only discussions
End-to-End Encryption (E2EE)
All messages are encrypted using the Megolm/Olm protocol (derived from the Signal protocol). Even the server admin cannot read messages — the server stores only encrypted blobs.
Closed Federation — Your Private Island
Unlike public Matrix servers (matrix.org), your hub uses closed federation. This means your server is completely isolated — no external servers can connect, no external users can join, and no metadata leaves your infrastructure.
Open
Open federation (public Matrix): Any server can talk to any other — like email. Your server discovers others via DNS.
Closed (Default)
Closed federation (hubport): Your server refuses ALL external connections. It's a private island. Messages, metadata, and user lists never leave your server.
Selective
Selective federation (optional): If congregations share a Kingdom Hall, they can explicitly allow federation with each other — while staying closed to everyone else.
Data Sovereignty
- ✓ All chat data stored in PostgreSQL on YOUR server (separate 'synapse' database)
- ✓ Media files stored locally (photos, documents shared in chat)
- ✓ No external servers involved — zero data leaves your infrastructure
- ✓ GDPR: deleting a publisher cascades to their chat account
- ✓ Backups: chat data included in regular Docker volume backups
Why not WhatsApp or Telegram?
WhatsApp: Messages on Meta's servers. Metadata (who, when, how often) visible to Meta. No self-hosting.
Telegram: Not end-to-end encrypted by default (only 'Secret Chats'). Server stores plaintext messages. Cloud-based.
Matrix (hubport): Self-hosted. All messages E2E encrypted. No metadata leaves your server. You own everything.
Who can access my congregation's data?
Only your congregation's tenant admin. We (the platform) have zero access to your data.
- ✓ Your database runs on YOUR server — we don't host it
- ✓ Keycloak (user management) runs on YOUR server — we don't control user accounts
- ✓ Vault (encryption keys) runs on YOUR server — we can't decrypt your data
- ✓ The Cloudflare Tunnel is just a network pipe — it carries encrypted traffic but can't read it
- ✓ We only store: your congregation name, contact email, and subdomain (for registration purposes)
- ✓ If you decommission, your local data stays on your server — we just remove the tunnel
How are congregations separated from each other?
Each congregation runs a completely independent Docker stack on its own server. There is no shared database, no shared users, and no shared infrastructure between congregations.
When does your congregation talk to the platform?
An API (Application Programming Interface) is simply a way for two computers to exchange information automatically — like a digital messenger. Here's when your congregation's server communicates with the hubport.cloud platform:
| When | What happens | Uses |
|---|---|---|
| Registration | You submit congregation name + email. The platform creates a tunnel and DNS record. | Platform API |
| Setup wizard | One-time call to confirm setup is complete. After this, no more platform contact. | Platform API (once) |
| Daily operation | Publisher management, territory maps, meetings — all local. No platform involvement. | Local only |
| Sharing (optional) | Only if you explicitly approve sharing with another congregation. | Platform API (opt-in) |
How do I get support?
Community support is available through GitHub Issues and Discussions. For urgent questions, use the contact form.