Privacy & Security

Data handling

What Alphorn stores

• Notification payloads — title, message, priority, tags, and custom payload data
• Delivery logs — timestamps, status codes, and error messages for each delivery attempt
• Channel configuration — webhook URLs, API keys, and credentials for your notification channels
• Account data — email address, organization memberships, and authentication details

What Alphorn doesn't do

• Alphorn does not sell or share your data with third parties
• Alphorn does not use your notification content for training, analytics, or advertising
• Alphorn does not track you across websites or services

Self-hosted: you control everything

When you self-host Alphorn, all data stays in your PostgreSQL database on your infrastructure. Nothing is sent to Alphorn's servers. You have full control over data retention, backups, and access.

Encryption

In transit

All communication with the hosted service at app.alphorn.dev uses TLS (HTTPS).

For self-hosted instances, configure TLS through your reverse proxy (Nginx, Caddy, Traefik). Caddy enables HTTPS automatically. For Nginx:

server {
    listen 443 ssl;
    server_name alphorn.example.com;

    ssl_certificate /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;

    location / {
        proxy_pass http://localhost:3000;
    }
}

At rest

Database encryption depends on your PostgreSQL configuration and hosting provider. Most managed PostgreSQL providers (AWS RDS, Supabase, Neon, etc.) encrypt data at rest by default. For self-managed PostgreSQL, configure disk encryption at the OS level.

Webhook security

Webhook URL tokens

Each webhook URL contains a unique, randomly generated ID (e.g., wh_abc123). These IDs are unguessable — they function as bearer tokens. Anyone with the URL can send notifications to that webhook.

Treat webhook URLs like API keys:

• Don't commit them to public repositories
• Don't log them in plain text
• Use environment variables or secrets management in CI/CD
• Rotate webhooks if you suspect a URL has been exposed

IP restrictions

For self-hosted instances, you can restrict webhook access at the network level using your reverse proxy or firewall to only accept requests from known source IPs.

Authentication security

Passwords

Alphorn uses Better Auth for authentication. Passwords are hashed using bcrypt before storage.

Two-factor authentication

Alphorn supports TOTP-based 2FA. Organization owners can enforce 2FA for all members. See Authentication for setup instructions.

SSO

Alphorn supports GitHub, Google, Microsoft, and any OIDC-compliant identity provider. SSO tokens are managed by Better Auth and stored server-side. See Authentication for details.

Session management

Sessions are server-side and signed with BETTER_AUTH_SECRET. Use a strong, random secret — generate one with:

openssl rand -base64 32

Channel credentials

Channel configuration (Slack webhook URLs, API keys, SMTP passwords, etc.) is stored in PostgreSQL. For self-hosted instances, secure your database access:

• Use strong PostgreSQL passwords
• Restrict database access to the Alphorn application only
• Use SSL connections to PostgreSQL in production
• Back up your database with encryption

Organizational isolation

Each organization is fully isolated:

• Webhooks, channels, and filtering rules are scoped to the organization
• Members can only access their own organizations
• Role-based access control limits who can manage configuration vs. view logs

Responsible disclosure

If you find a security vulnerability in Alphorn, please report it privately through GitHub Security Advisories rather than opening a public issue.