Security and reliability of CUZY Hosting

1. Architecture and isolation

• One container per community. Each HumHub community runs in its own Docker container with its own HumHub version, its own configuration and its own file storage. Containers cannot see each other's files or processes.
• One database per community. Each community has a dedicated database with its own credentials, which only that community's container can use. The cache layer is likewise partitioned per community and enforced by the cache server itself, not just by configuration.
• Resource limits. Memory and CPU limits per container prevent one busy community from starving its neighbors.
• Encrypted traffic everywhere. All connections to your community use HTTPS with automatically renewed certificates. Plain HTTP is never served. Custom domains get their own certificates.
• Separate control plane. The systems that provision and manage communities run on separate servers from the communities themselves. If our management platform were unavailable, running communities would be unaffected.
• Open source foundation. HumHub is open source and we run the official HumHub container image, so the software your community runs can be inspected by anyone.

Back to top

2. Where your data is

• Production servers are hosted by Hetzner in ISO 27001 certified data centers, in Germany (Nuremberg and Falkenstein), in the United States and in Singapore.
• The region is chosen when the community is created and is shown in your customer account. Germany and the USA are available immediately; a Singapore community is set up within two business days, and we tell you so before you start. Moving a community to another region is done by us on request, with a short maintenance window.
• Backups are stored with a second, independent provider in the same region, so a problem at one provider never affects both your live data and your backups. One exception: our backup provider has no data center in Asia, so backups of Singapore communities are stored in the United States. They are encrypted before they leave the server, so the provider never sees readable data, and the Data Processing Agreement states the transfer.
• Your community data is not copied outside its region. Some sub-processors we use for payments, email and DNS operate internationally; for European customers the transfers are covered by Standard Contractual Clauses, and all of them are listed in the Data Processing Agreement.
• European customers who need data to stay in the European Union choose the Germany (EU) region, which is the default.

Back to top

3. Backups and recovery

How backups work

• Scope. The full database, uploaded files, configuration, installed modules and themes: everything needed to rebuild the community.
• Encryption. Backups are encrypted on the server before upload with keys that are never stored alongside the backup data.
• Isolation. Every community has its own backup repository. Restoring or deleting one customer's backups can never touch another's.
• Protection against deletion. The backup storage keeps deleted and overwritten versions for a retention period, so even a compromised server or an operator mistake cannot destroy backups immediately.
• Verification. Backup integrity is checked automatically every week, and real restores into a scratch environment are performed on the schedule above and recorded.
• Before every change. An additional backup is taken automatically before every upgrade and before any deletion.
• Monitoring of the backups themselves. A missing or failed backup raises an alert; silence is treated as a failure, not as success.

Back to top

4. Monitoring and alerting

• Availability checks of every community every minute from outside our infrastructure, with certificate expiry tracking.
• Server health (CPU, memory, disk, network) with early warnings well before capacity is reached, so servers are extended or communities moved before users notice.
• Application health. Each community reports its own health regularly: background jobs, scheduled tasks, errors, storage use and version. Only counts and technical status are reported, never your members' content or personal data.
• Backups, email delivery, DNS and certificates are checked continuously as well; see the dedicated sections.
• Independent watchdog. Our monitoring is itself monitored by an external service, so a failure of the monitoring cannot go unnoticed.
• Alerting that works when email does not. Alerts are delivered by push notification to on-call devices as well as by email, so an email outage cannot silence them. Alerts are de-duplicated and rate limited so that real problems stand out.
• Assisted diagnosis. Critical alerts are automatically analyzed against logs, recent changes and known issues, and the summary is attached to the alert, which shortens the time to a fix at any hour.
• Logs. Application and system logs are retained for a short, defined period for troubleshooting and then deleted. They are never used for any other purpose.

Back to top

5. Updates and patching

• Operating system. Security updates are installed automatically on every server. Restarts, when needed, happen in announced maintenance windows.
• HumHub and modules. Upgrades are performed by our team, never by an unattended process. Each upgrade is preceded by a backup, rolled out progressively (a small group of communities first, then the rest) and verified by health checks. You can request an upgrade to a newer version from your customer account.
• Emergency fixes. When a security issue is published in HumHub, a module or the platform, a fix can be applied to all communities within hours through a hotfix pipeline, then made permanent in the next image build.
• Platform components (web proxy, database, cache, deployment tooling) are pinned to known versions, and security releases are applied on a defined schedule after being tested on a staging environment.
• Watching for new risks. Security advisories for every component we run, vulnerability databases, provider incident feeds and changes in industry rules (certificates, email authentication) are collected automatically and reviewed. Critical advisories affecting our exact versions raise an immediate alert.
• Supply chain. Container images are built from the official HumHub image, scanned for known vulnerabilities before they are published, and shipped with a software bill of materials. Dependencies are pinned and updated through reviewed changes.

Back to top

6. Who can access your community

• Your administrators manage the community exactly as with a self-hosted HumHub. Your member accounts are completely separate from your CUZY customer account.
• Support access by CUZY staff uses one-time login links that expire within minutes. Every use is recorded, shown to your administrators inside the community, and you can switch the feature off at any time.
• Operational access to servers is limited to named staff, with key-based authentication only, from restricted networks, and all administrative interfaces are shielded from the public internet.
• Secrets such as database credentials and API keys are never stored in code repositories. They are stored encrypted, rotated regularly and immediately if a leak is suspected.
• No content access in routine operations. Health reports, alerts and diagnostics work on counts and technical data. Backups are only ever restored to the community they came from, or to a test environment for restore drills.

Back to top

7. Protection against attacks

• Server hardening. Every server is built from the same audited configuration (operating system hardening following the DevSec baseline, firewall allowing only web traffic and administrative access from restricted networks, intrusion blocking on remote access, weekly security audits).
• Brute force. Login, password-recovery and registration pages are rate limited per client, and HumHub adds its own throttling and captcha after repeated failures.
• Denial of service. Traffic anomalies are detected by monitoring, and a global content-delivery and DDoS protection layer can be enabled in front of any community within minutes.
• Abuse of the platform. Trial signups require email verification and are rate limited; each community has resource limits; sending limits protect email reputation; an acceptable use policy applies.
• Vulnerabilities. Advisories are monitored automatically (see Updates), and fixes are rolled out through the hotfix pipeline.
• Compromise response. Should a server be compromised, it is isolated, every secret it held is rotated, the server is rebuilt from configuration, and communities are restored from clean backups.
• Assistants with limits. The AI tools that help our team analyze incidents and draft support answers can only read; they cannot change anything on servers or in communities, and they never receive your members' personal data.

Back to top

8. Email delivery and authentication

• Emails from communities are sent from a dedicated sending domain with SPF, DKIM and DMARC authentication, separate from the domain used for CUZY's own platform emails, so one cannot affect the other's reputation.
• Delivery, bounce and complaint rates are monitored, and mails carry the one-click unsubscribe headers that major mailbox providers require, pointing to each member's notification settings.
• Sending limits per community protect all customers from the reputation impact of an abusive sender.
• We regularly send a test email and confirm its receipt automatically, so an outage of email delivery is detected within the hour rather than reported by users.
• Business plans can send from their own domain after a guided DNS setup.

Back to top

9. When something breaks

• Server loss. Servers carry no manual configuration; they are rebuilt automatically from our infrastructure code. Communities on a lost server are restored from their backups onto a replacement server within the recovery time of their plan.
• Loss of our management platform. Running communities are unaffected; only new signups, support and management pause. A documented recovery procedure rebuilds the platform from backups within hours, and it is rehearsed.
• Provider capacity or outages. We keep capacity headroom, spread servers across data centers and regions, and maintain the ability to rebuild on a second hosting provider if needed.
• Data mistakes. Accidental deletion by an administrator can be reversed from the backup snapshots; deleted communities keep their data for a grace period before permanent deletion.
• Runbooks. Every failure scenario in our risk register has a written detection, prevention and response procedure, and the register is reviewed quarterly and updated as new risks are identified.
• Transparency. A public status page shows current availability. Incidents affecting your community are communicated to your administrators with what happened and what was done.

Back to top

10. Data protection and GDPR

• Roles. For the personal data inside your community, you are the controller and CUZY is the processor. For your customer account and billing data, CUZY is the controller, covered by our Privacy Policy.
• Data Processing Agreement. Accepted online when you subscribe, versioned, always available for download. You are informed before any change of sub-processor.
• Sub-processors. Hosting (Hetzner: Germany, United States, Singapore), backup storage (Backblaze, in the same region as the community; United States for Singapore communities), payments (Stripe), transactional email (SMTP2GO), DNS (Cloudflare), and AI assistance (Anthropic: for our internal operations it receives only technical data with personal data removed; for our support desk it receives the text of support tickets written by administrators, never your members' content). The complete, current list is in the DPA.
• Data minimization. Health reports contain counts only; logs are scrubbed of personal data before any automated analysis and kept for a short, defined period.
• Retention and deletion. When a community is deleted, its data is removed from production immediately, kept in backups only for the defined retention period, then purged, and the purge is logged. Trial communities that are not converted are deleted automatically after a notice period.
• Data subject rights. HumHub gives your administrators the tools to export, correct and delete member data. For requests about CUZY customer accounts, contact us directly.
• Breach process. A documented procedure covers containment, assessment, notification to the supervisory authority within 72 hours where required, and information to affected controllers.
• Legal templates. Every community comes with ready-to-adapt imprint, terms, privacy and cookie pages and a GDPR checklist for community operators.

Back to top

11. Your data, your exit

• Subscribers can download a complete export of their database and files from the customer account, once a day, as a secure, time-limited download. Exports are not available during the free trial.
• Team and Business plans include read-only file access to your community's storage. planned
• The export is a standard HumHub installation: it can be imported into a self-hosted HumHub or another provider.
• Subscriptions are monthly or yearly and can be canceled from your account; access continues to the end of the paid period, followed by a grace period before deletion.

Back to top

12. What we ask of you

• Use strong, unique passwords for your administrator accounts and keep the number of administrators small.
• Review who can register in your community and what guests can see.
• Adapt the legal templates to your organization and publish them.
• Report anything suspicious to our support; the sooner we know, the faster we act.
• Keep your customer account email reachable: it is where we send security and maintenance notices.

Back to top

13. Reporting a security problem

Write to security@cuzy.app. The address is also published in /.well-known/security.txt, which is where automated scanners and most researchers look first.

• What we promise. We acknowledge a report within two working days, tell you within ten working days whether we consider it a vulnerability and what we intend to do, and let you know when the fix ships. We will credit you by name if you want, and we will never take legal action against research that follows the rules below.
• In scope. The CUZY platform: www.cuzy.app, the hosting dashboard, the hosted communities on *.cuzy.app where you are the administrator or have that administrator's permission, and the CUZY modules we publish.
• Out of scope. Anything that touches a community you have no permission for, denial of service, automated scanning that degrades service for others, social engineering of our staff or customers, physical attacks, and reports produced by a scanner without a demonstrated impact. HumHub itself is a separate project — send core findings to HumHub GmbH, and tell us so we can apply the fix quickly.
• The rules. Use your own account and your own test community; stop as soon as you can show a problem; do not read, copy, change or delete anyone else's data; give us a reasonable time to fix it before publishing, and we will agree on a date together rather than a fixed number of days.

We do not pay bounties today. Serious reports are answered by a person, fixed within the deadlines of the update policy above, and disclosed in the changelog of the module or image concerned.

Back to top

14. Roadmap

Items marked planned above are scheduled after launch, in this order: read-only file access for customers, immutable monthly archives and point-in-time recovery for Business, a second backup copy with another provider, additional hosting regions, and a customer-visible uptime history. This page is updated when they ship.

Back to top