Security & data handling — installed platform

What runs on your server, where the data goes, and how we handle credentials.

1. Installation model

The platform is fully self-hosted. The customer owns the VPS and everything on it.

• We install via SSH on the customer's server. Install is a set of open-source shell scripts that pull pinned container images.
• During install, we generate strong random admin passwords (24-character base64) for each product and write them to /root/ntj-platform/docker/.env with permissions 600.
• After install, we hand over root SSH access and the .env file. We do not retain a copy.
• The platform does not phone home. There is no usage telemetry from the platform itself to us.

2. Data location

Customer data lives only on the customer's VPS. Nothing is streamed to N.T.J.

• The VPS provider is the customer's choice. If we host it on the customer's behalf on Hetzner (Germany or Finland data centres), Hetzner is a sub-processor.
• We do not access customer data unless the customer explicitly grants SSH access for a support session. Support sessions are audit-logged on the customer's server via the standard system auth log.

3. Encryption

In transit. All product interfaces are served over HTTPS using certificates from Let's Encrypt, renewed automatically. HSTS is enabled. TLS 1.2 or higher only.

At rest. Filesystem encryption is configurable at the VPS layer, which the customer controls. Hetzner offers full-disk encryption on request; most other reputable providers offer the same. We do not add a second application-layer encryption pass — the design assumption is that the disk is the encryption boundary.

Backups. Backup archives are encrypted with a customer-supplied passphrase using age or GPG symmetric encryption. The passphrase never leaves the customer's hands. If they lose it, we cannot recover the backup — this is by design.

4. Credentials and access

• All admin passwords are generated randomly at install — we do not use defaults, and no human ever types them.
• Passwords are stored only in /root/ntj-platform/docker/.env on the customer's VPS, with permissions 600 (readable only by root).
• The customer can rotate any admin password from within each product's built-in admin UI. Rotation does not require our involvement.
• SMTP credentials are the customer's own. We never store them, and we never use them for any purpose of our own.
• Two-factor authentication is enabled by default on Crewix (EspoCRM) and Cloudzy (Nextcloud). It is available on all other products and can be enabled through each product's admin UI.

5. Sub-processors (installed platform)

For an installed platform, the sub-processor list is short and depends on where the customer chooses to run it.

• Hetzner Online GmbH — VPS provider, if the customer asks us to host on Hetzner (Germany or Finland). Privacy policy: hetzner.com/legal/privacy-policy.
• Let's Encrypt (ISRG) — issues the TLS certificates used by the platform.
• Docker Hub — distributes container images. All images are pinned to specific versions, not :latest.

If the customer chooses their own VPS provider (DigitalOcean, OVH, AWS Lightsail, on-premises, anything else), that provider is their sub-processor, not ours.

6. Backups and recovery

• Daily backups via cron — the customer opts in during install.
• 14-day retention on the VPS by default.
• Archives are encrypted with the customer's passphrase (see section 3).
• The off-site copy is the customer's responsibility. We recommend syncing encrypted archives to a cold storage bucket the customer already trusts — Backblaze B2, S3 Glacier, or equivalent.
• The restore procedure is documented in scripts/restore.sh, which is open source and shipped with the install.

7. Updates and patch policy

• We publish a monthly compose file update with pinned image bumps for all products.
• The customer runs scripts/upgrade.sh when it is convenient for them. Updates are always additive — we do not force auto-updates and cannot push changes to a customer's VPS without them running the script.
• For critical security patches, we email affected customers within 48 hours of the upstream advisory, with the specific upgrade command they should run.

8. Incident response

9. What we do not offer (today)

To save your team time on the security questionnaire, here is what we do not currently have. If any of these are hard requirements for your organisation, please tell us early.

• No SOC 2 or ISO 27001 certification. We are a small team. A formal audit is on our roadmap for year 3.
• No 24/7 support. Support runs during business hours across the UTC+2 and UTC+8 time zones, Monday to Friday.
• No formal uptime SLA for self-hosted installs — the uptime of the VPS is the customer's responsibility. We do commit to response times on support and security advisories, as described above.
• No dedicated CISO. Security decisions are made by the founders.

None of these are permanent choices — they reflect where we honestly are today. We would rather tell you now than in an audit response.

10. Contact for security questions

Please email contact@ntjtech.com with the subject line "Security review" for faster routing. We are happy to answer follow-up questionnaires and to talk directly with your IT or security team.

Last reviewed 11 July 2026. We will update this page when the platform's architecture or practices change.