Skip to content
Security

How it is built, and what to harden.

The technical detail behind the trust page: what runs, how it is isolated, how updates are verified, and what you should configure yourself.

Architecture

What runs on your server.

Dashboard
The web app your team uses. Not exposed directly; it is reached only through the reverse proxy.
Seven agents
Research, Audit, Technical SEO, Content Engine, Publishing, Monitoring, Optimization. Each runs as its own container.
Postgres 16
The application database: clients, drafts, review history, settings.
ClickHouse 24.8
The analytics warehouse for search and traffic metrics.
nginx 1.27
The reverse proxy: port 80 redirects to 443, and 443 is the only way into the dashboard.
Updater
Applies updates after verifying signatures. The only core container with Docker socket access.
Backup
Writes a daily compressed database dump to a local volume.
Optional
Self-hosted Firecrawl, the Airbyte data pipeline and a metrics exporter. Off unless you enable their profiles.
Controls

What is in place today.

Network isolation

Services talk to each other over an internal network that has no outside access. The dashboard and agents also join an external network, because they need to reach AI providers, your CMS and our release server. Postgres and ClickHouse ports are bound to localhost only, and the dashboard publishes no ports.

TLS and headers

Plain HTTP only redirects to HTTPS. TLS 1.2 and 1.3 are enabled, with HSTS, X-Frame-Options, X-Content-Type-Options, a referrer policy and a permissions policy set at the proxy. A self-signed certificate is generated on first install; replace it with a real one before production use.

Sign-in and access

Dashboard sign-in uses Google OAuth. The dashboard has roles: managers see every client, and editors see the clients assigned to them. Secrets such as database passwords, the authentication secret and the encryption key live in your own environment file, not in the images.

Signed updates

An update is applied only if three checks pass. First, the release instruction from our release server must carry a valid signature against a public key built into the updater. Second, every application image must carry a signature tied to our CI pipeline's identity. Third, the downloaded image digest must match the registered checksum. The updater also refuses a release that is not newer than the one you run, so a replayed older instruction cannot downgrade you. Updates are either applied by you from the dashboard or, if you turn it on, automatically.

Backups

A daily dump of the application database is written to a local volume and kept for 14 days by default. See the checklist below: the dump stays on the same host unless you copy it off, and the warehouse is backed up separately.

You are trusting us to sign updates responsibly: an automatic update changes the code running on your server. That is why updates are signed and verified, why you can choose manual updates, and why you can pin a version.

Your side

A hardening checklist for your deployment.

Self-hosting moves responsibility to you. We do the setup with you on a call, and this is the list we go through.

  1. 01Replace the self-signed certificate with a real one before anyone outside your team uses the dashboard.
  2. 02Pin the release version (ALTYZO_VERSION) instead of leaving it on latest, and decide whether to turn automatic updates on.
  3. 03Copy database backups off the host. The backup service writes to a local volume only.
  4. 04Back up the ClickHouse warehouse separately; the backup service covers the application database only.
  5. 05Set strong, unique values for every password and secret in the environment file, including those for optional components.
  6. 06If you enable the optional Airbyte pipeline, review its settings: it mounts the Docker socket and has its own usage-tracking setting.
  7. 07Restrict who can reach ports 80 and 443 to your team's network where you can.
  8. 08Use API keys scoped to this deployment for each AI provider, so you can revoke them without touching other systems.
Reporting a vulnerability

Found something? Tell us.

Email support@altyzo.com with the subject “Security”. Include what you found, how to reproduce it and which version you ran. We read every report and reply within 5 business days. Please give us reasonable time to fix an issue before you publish it, and do not access other customers' data. A machine-readable version is at /.well-known/security.txt.

We do not run a paid bounty yet. We will credit you if you want it.