Deploying Authelia

Introduction

Authelia is a powerful open-source authentication and authorization server that provides comprehensive single sign-on (SSO) and multi-factor authentication (MFA) capabilities for your applications and services. With support for two-factor authentication via TOTP (Time-based One-Time Password), WebAuthn, Duo Push, and security keys, Authelia acts as a robust identity provider that integrates seamlessly with reverse proxies like NGINX, Traefik, Caddy, and HAProxy to secure your web applications.

Deploying Authelia on Klutch.sh provides enterprise-grade infrastructure for implementing zero-trust security models, protecting sensitive applications, and managing user authentication across your entire application stack. Whether you’re securing internal tools, protecting API endpoints, implementing SSO for SaaS applications, or building a complete identity and access management (IAM) solution, Klutch.sh simplifies the deployment process with automated Docker builds, persistent storage for configuration and session data, secure environment variable management, and production-ready scaling capabilities.

This comprehensive guide walks you through deploying Authelia on Klutch.sh using a Dockerfile, configuring Redis for session storage, setting up MySQL or PostgreSQL for user data persistence, implementing LDAP or Active Directory authentication backends, managing persistent volumes for configuration files and encryption keys, configuring SMTP for password resets and notifications, and implementing production security best practices for protecting your authentication infrastructure.

Prerequisites

Before you begin deploying Authelia on Klutch.sh, ensure you have:

A Klutch.sh account (sign up here)
A GitHub repository for your Authelia deployment configuration
Access to the Klutch.sh dashboard
Basic understanding of Docker containers, authentication concepts, and YAML configuration
(Required for production) A Redis instance for session storage and caching
(Required for production) A MySQL, PostgreSQL, or MariaDB database for user data and configuration
(Optional) An LDAP server or Active Directory for user authentication
(Optional) An SMTP server for sending password reset emails and notifications
(Optional) Domain names for your applications and Authelia portal

Understanding Authelia Architecture

Authelia consists of several key components that work together to provide comprehensive authentication and authorization:

Authentication Portal: Web interface for user login, password reset, two-factor authentication enrollment, and session management
Authorization Engine: Policy engine that evaluates access control rules based on user identity, group membership, network location, and request context
Session Storage: Redis-based session management for maintaining authenticated user sessions across services
User Database: MySQL, PostgreSQL, MariaDB, or SQLite storage for user credentials, MFA devices, and authentication preferences
LDAP/AD Integration: Optional backend for authenticating users against existing directory services
SMTP Integration: Email service for password resets, device registration confirmations, and security notifications
Configuration Files: YAML-based configuration defining authentication policies, access rules, session settings, and integration parameters

When deployed on Klutch.sh, Authelia automatically detects your Dockerfile and builds a container image. The platform manages traffic routing to port 9091 (Authelia’s default HTTP port), provides SSL termination, and offers persistent storage options for your configuration files and encryption keys.

Project Structure

A minimal repository structure for deploying Authelia on Klutch.sh:

authelia-deployment/
├── Dockerfile
├── .dockerignore
├── .gitignore
├── README.md
├── configuration-template.yml
└── users-template.yml

Important Security Note: Never commit actual configuration files containing secrets, encryption keys, or user passwords to your repository. Use configuration templates and inject sensitive values via environment variables or mount them from persistent volumes at runtime.

Creating Your Dockerfile

Klutch.sh automatically detects a Dockerfile in the root directory of your repository. Create a Dockerfile that uses the official Authelia image as the base:

Option 1: Simple Dockerfile (Quick Start)

FROM authelia/authelia:latest

# Expose Authelia's default HTTP port
EXPOSE 9091

# The official image includes the Authelia binary as entrypoint
CMD ["authelia"]

Option 2: Production Dockerfile with Configuration Management

FROM authelia/authelia:4.38

# Set working directory for configuration
WORKDIR /config

# Create necessary directories
RUN mkdir -p /config /secrets

# Expose Authelia's HTTP port
EXPOSE 9091

# Health check for monitoring
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:9091/api/health || exit 1

# Run Authelia with configuration from /config
CMD ["authelia", "--config", "/config/configuration.yml"]

Option 3: Advanced Dockerfile with Custom Scripts

FROM authelia/authelia:4.38

# Install additional utilities for debugging and health checks
USER root
RUN apk add --no-cache curl wget ca-certificates

# Create configuration and secrets directories
RUN mkdir -p /config /secrets /data && \
    chown -R authelia:authelia /config /secrets /data

# Copy configuration template (secrets will be mounted at runtime)
COPY --chown=authelia:authelia configuration-template.yml /config/

# Switch back to authelia user for security
USER authelia

WORKDIR /config

# Expose HTTP port
EXPOSE 9091

# Health check
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:9091/api/health || exit 1

# Start Authelia
CMD ["authelia", "--config", "/config/configuration.yml"]

Important Notes:

Authelia’s official image listens on port 9091 by default for HTTP traffic
Klutch.sh will route external HTTP traffic to port 9091 in your container
Configuration files should be mounted from persistent volumes, not baked into the image
Secrets and encryption keys must be managed via environment variables or mounted from secure storage
The Authelia process runs as a non-root user (authelia) for security

Configuration File Template

Create a configuration-template.yml file that serves as a template for your Authelia configuration. Sensitive values will be injected via environment variables:

---
# Authelia Configuration Template
# Sensitive values should be injected via environment variables

server:
  host: 0.0.0.0
  port: 9091

log:
  level: info
  format: text

theme: light

jwt_secret: JWT_SECRET_PLACEHOLDER

default_redirection_url: https://example-app.klutch.sh

totp:
  issuer: authelia.com
  period: 30
  skew: 1

authentication_backend:
  file:
    path: /config/users.yml
    password:
      algorithm: argon2id
      iterations: 1
      key_length: 32
      salt_length: 16
      memory: 1024
      parallelism: 8

access_control:
  default_policy: deny
  rules:
    - domain: "*.example-app.klutch.sh"
      policy: two_factor

session:
  name: authelia_session
  secret: SESSION_SECRET_PLACEHOLDER
  expiration: 3600
  inactivity: 300
  domain: example-app.klutch.sh

  redis:
    host: REDIS_HOST_PLACEHOLDER
    port: 6379
    password: REDIS_PASSWORD_PLACEHOLDER
    database_index: 0

regulation:
  max_retries: 3
  find_time: 120
  ban_time: 300

storage:
  encryption_key: STORAGE_ENCRYPTION_KEY_PLACEHOLDER

  mysql:
    host: MYSQL_HOST_PLACEHOLDER
    port: 3306
    database: authelia
    username: MYSQL_USER_PLACEHOLDER
    password: MYSQL_PASSWORD_PLACEHOLDER

notifier:
  smtp:
    host: SMTP_HOST_PLACEHOLDER
    port: 587
    username: SMTP_USERNAME_PLACEHOLDER
    password: SMTP_PASSWORD_PLACEHOLDER
    sender: noreply@example.com
    subject: "[Authelia] {title}"

Deploying to Klutch.sh

Create Your Repository

Create a new GitHub repository and add your Dockerfile and configuration template:

mkdir authelia-deployment
cd authelia-deployment

# Create Dockerfile
cat > Dockerfile << 'EOF'
FROM authelia/authelia:4.38

WORKDIR /config

RUN mkdir -p /config /secrets

EXPOSE 9091

HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
  CMD wget --no-verbose --tries=1 --spider http://localhost:9091/api/health || exit 1

CMD ["authelia", "--config", "/config/configuration.yml"]
EOF

# Create .gitignore to exclude sensitive files
cat > .gitignore << 'EOF'
configuration.yml
users.yml
secrets/
*.key
*.pem
.env
.DS_Store
EOF

# Initialize git and push
git init
git add .
git commit -m "Initial Authelia deployment setup"
git remote add origin https://github.com/YOUR_USERNAME/authelia-deployment.git
git push -u origin main

Access the Klutch.sh Dashboard

Navigate to klutch.sh/app and log in to your account.
Create a New Project
- Click “New Project” in the dashboard
- Enter a project name (e.g., “Authentication Services”)
- Select your preferred region for deployment
Create a New Application
- Within your project, click “New App”
- Name your application (e.g., “Authelia”)
- Connect your GitHub repository containing the Dockerfile
Configure Traffic Settings
- In the app settings, select HTTP as the traffic type
- Authelia serves web traffic on HTTP and should use HTTP routing
- Set the internal port to 9091 (Authelia’s default HTTP port)
Set Up Persistent Storage

Authelia requires persistent storage for configuration files and encryption keys:
- In the app settings, navigate to the “Volumes” section
- Click “Add Volume”
- Set the mount path to /config
- Set the volume size (recommended: 1GB for configuration and user data)
- Click “Add” to attach the volume
Optional: Add another volume for SQLite storage if not using external database:
- Mount path: /data
- Size: 5GB (depending on expected user count and session history)
Critical: The /config directory stores:
- configuration.yml - Main Authelia configuration
- users.yml - User database (if using file-based authentication)
- Encryption keys and secrets
- Session data (if not using Redis)
Set Up Redis (Required for Production)

Authelia requires Redis for session storage in production environments:
- Deploy a Redis instance on Klutch.sh or use an external Redis service
- Note the Redis hostname, port, and password
- Redis will be configured via environment variables in the next step
Set Up Database (Required for Production)

Deploy a MySQL, PostgreSQL, or MariaDB instance for storing Authelia data:
- Create a database instance on Klutch.sh or use an external database service
- Create a database named authelia
- Create a dedicated user with full permissions on the authelia database
- Note the database hostname, port, username, and password

Configure Environment Variables

In the app settings, add the following required environment variables for Nixpacks customization:

Essential Security Variables:

# Generate with: openssl rand -hex 64
AUTHELIA_JWT_SECRET=your-strong-jwt-secret-min-64-chars
AUTHELIA_SESSION_SECRET=your-strong-session-secret-min-64-chars
AUTHELIA_STORAGE_ENCRYPTION_KEY=your-storage-encryption-key-min-64-chars

Redis Configuration:

AUTHELIA_SESSION_REDIS_HOST=redis-host.klutch.sh
AUTHELIA_SESSION_REDIS_PORT=6379
AUTHELIA_SESSION_REDIS_PASSWORD=your-redis-password

Database Configuration (MySQL Example):

AUTHELIA_STORAGE_MYSQL_HOST=mysql-host.klutch.sh
AUTHELIA_STORAGE_MYSQL_PORT=3306
AUTHELIA_STORAGE_MYSQL_DATABASE=authelia
AUTHELIA_STORAGE_MYSQL_USERNAME=authelia_user
AUTHELIA_STORAGE_MYSQL_PASSWORD=your-database-password

PostgreSQL Alternative:

AUTHELIA_STORAGE_POSTGRES_HOST=postgres-host.klutch.sh
AUTHELIA_STORAGE_POSTGRES_PORT=5432
AUTHELIA_STORAGE_POSTGRES_DATABASE=authelia
AUTHELIA_STORAGE_POSTGRES_USERNAME=authelia_user
AUTHELIA_STORAGE_POSTGRES_PASSWORD=your-database-password

Domain and Portal Configuration:

AUTHELIA_DEFAULT_REDIRECTION_URL=https://example-app.klutch.sh
AUTHELIA_SESSION_DOMAIN=klutch.sh

Optional SMTP Configuration:

AUTHELIA_NOTIFIER_SMTP_HOST=smtp.gmail.com
AUTHELIA_NOTIFIER_SMTP_PORT=587
AUTHELIA_NOTIFIER_SMTP_USERNAME=your-email@gmail.com
AUTHELIA_NOTIFIER_SMTP_PASSWORD=your-app-password
AUTHELIA_NOTIFIER_SMTP_SENDER=noreply@yourdomain.com

Optional LDAP Configuration:

AUTHELIA_AUTHENTICATION_BACKEND_LDAP_URL=ldap://ldap.example.com
AUTHELIA_AUTHENTICATION_BACKEND_LDAP_BASE_DN=dc=example,dc=com
AUTHELIA_AUTHENTICATION_BACKEND_LDAP_USER=cn=admin,dc=example,dc=com
AUTHELIA_AUTHENTICATION_BACKEND_LDAP_PASSWORD=ldap-admin-password

Create Configuration File

After the initial deployment, you’ll need to create the actual configuration.yml file in the persistent volume. You can do this by:

Using Klutch.sh’s file editor (if available) to create /config/configuration.yml
Or deploying with a basic configuration and updating it via environment variables
Or using a one-time job or init container to copy the template

For simplicity, you can create a minimal configuration that relies heavily on environment variables:

---
server:
  host: 0.0.0.0
  port: 9091

log:
  level: info

# Secrets injected via environment variables
jwt_secret: ${AUTHELIA_JWT_SECRET}

default_redirection_url: ${AUTHELIA_DEFAULT_REDIRECTION_URL}

totp:
  issuer: authelia.com

authentication_backend:
  file:
    path: /config/users.yml

access_control:
  default_policy: deny
  rules:
    - domain: "*.klutch.sh"
      policy: one_factor

session:
  secret: ${AUTHELIA_SESSION_SECRET}
  domain: ${AUTHELIA_SESSION_DOMAIN}
  redis:
    host: ${AUTHELIA_SESSION_REDIS_HOST}
    port: ${AUTHELIA_SESSION_REDIS_PORT}
    password: ${AUTHELIA_SESSION_REDIS_PASSWORD}

storage:
  encryption_key: ${AUTHELIA_STORAGE_ENCRYPTION_KEY}
  mysql:
    host: ${AUTHELIA_STORAGE_MYSQL_HOST}
    port: ${AUTHELIA_STORAGE_MYSQL_PORT}
    database: ${AUTHELIA_STORAGE_MYSQL_DATABASE}
    username: ${AUTHELIA_STORAGE_MYSQL_USERNAME}
    password: ${AUTHELIA_STORAGE_MYSQL_PASSWORD}

notifier:
  filesystem:
    filename: /config/notification.txt

Deploy the Application
- Review all configuration settings
- Click “Deploy” to start the build process
- Klutch.sh will automatically detect your Dockerfile, build the container, and deploy it
- Monitor the build logs for any errors
Verify Deployment

Once deployment completes:
- Access your Authelia portal at the provided Klutch.sh URL (e.g., https://authelia-abc123.klutch.sh)
- You should see the Authelia login page
- Test authentication with your configured users

Creating User Accounts

For file-based authentication, create a users.yml file in the /config volume:

---
users:
  john:
    displayname: "John Doe"
    password: "$argon2id$v=19$m=65536,t=3,p=4$BpLnfgDsc2WD8F2q$o/vzA4myCqZZ36bUGsDY//8mKUYNZZaR0t4MFFSs+iM"
    email: john.doe@example.com
    groups:
      - admins
      - dev

  jane:
    displayname: "Jane Smith"
    password: "$argon2id$v=19$m=65536,t=3,p=4$c2FsdHlzYWx0$IEhJSklLTE1OT1BRUlNUVVZXWFlaYWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXo"
    email: jane.smith@example.com
    groups:
      - admins

Generate password hashes:

# Using the authelia binary
docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'your-password'

# Or using a password hashing tool
authelia crypto hash generate argon2 --password 'your-password'

Access Control Rules

Configure access control policies in your configuration.yml:

access_control:
  default_policy: deny

  rules:
    # Public access to specific paths
    - domain: "example-app.klutch.sh"
      policy: bypass
      resources:
        - "^/api/public.*$"
        - "^/health$"

    # Single-factor authentication for read-only access
    - domain: "example-app.klutch.sh"
      policy: one_factor
      resources:
        - "^/dashboard.*$"

    # Two-factor authentication for admin access
    - domain: "example-app.klutch.sh"
      policy: two_factor
      resources:
        - "^/admin.*$"
      subject:
        - "group:admins"

    # Network-based access control
    - domain: "internal.example-app.klutch.sh"
      policy: bypass
      networks:
        - "10.0.0.0/8"
        - "192.168.0.0/16"

    # Deny all other access
    - domain: "*"
      policy: deny

Database Storage Options

SQLite (Development Only)

For quick testing, you can use SQLite:

storage:
  encryption_key: ${AUTHELIA_STORAGE_ENCRYPTION_KEY}
  local:
    path: /config/db.sqlite3

Warning: SQLite is not recommended for production use due to performance limitations and lack of concurrent access support.

MySQL (Recommended for Production)

storage:
  encryption_key: ${AUTHELIA_STORAGE_ENCRYPTION_KEY}
  mysql:
    host: ${AUTHELIA_STORAGE_MYSQL_HOST}
    port: ${AUTHELIA_STORAGE_MYSQL_PORT}
    database: authelia
    username: ${AUTHELIA_STORAGE_MYSQL_USERNAME}
    password: ${AUTHELIA_STORAGE_MYSQL_PASSWORD}
    timeout: 5s

PostgreSQL (Recommended for Production)

storage:
  encryption_key: ${AUTHELIA_STORAGE_ENCRYPTION_KEY}
  postgres:
    host: ${AUTHELIA_STORAGE_POSTGRES_HOST}
    port: ${AUTHELIA_STORAGE_POSTGRES_PORT}
    database: authelia
    username: ${AUTHELIA_STORAGE_POSTGRES_USERNAME}
    password: ${AUTHELIA_STORAGE_POSTGRES_PASSWORD}
    timeout: 5s
    schema: public
    ssl:
      mode: disable

Integrating with Applications

To protect your applications with Authelia, you need to configure your reverse proxy or application to use Authelia for authentication. Here’s an example for common scenarios:

Basic Integration Concept

User requests protected resource
Reverse proxy/application redirects to Authelia portal
User authenticates with username/password
User completes second factor (if required by policy)
Authelia creates session and redirects back to application
Application verifies session with Authelia on subsequent requests

Example: Protecting an Application on Klutch.sh

If you’re running applications on Klutch.sh that need authentication, you can:

Deploy Authelia as described in this guide
Configure Authelia’s access control rules for your application domains
Modify your application to check authentication headers from Authelia
Use Authelia’s forward auth API endpoint: http://authelia:9091/api/verify

For detailed integration examples with specific reverse proxies and applications, refer to the Authelia Integration Documentation.

Custom Domain Configuration

To use a custom domain with Authelia:

Add Custom Domain in Klutch.sh
- Navigate to your Authelia app settings
- Go to the “Domains” section
- Add your custom domain (e.g., auth.yourdomain.com)
- Klutch.sh will automatically provision SSL/TLS certificates
Update DNS Records
- Create a CNAME or A record pointing to your Klutch.sh app
- Follow the DNS instructions provided in the Klutch.sh dashboard
Update Authelia Configuration

Update your environment variables or configuration file:
Terminal window
```
AUTHELIA_DEFAULT_REDIRECTION_URL=https://auth.yourdomain.com
AUTHELIA_SESSION_DOMAIN=yourdomain.com
```

Update Access Control Rules

Modify your configuration.yml to use your custom domain:

access_control:
  rules:
    - domain: "*.yourdomain.com"
      policy: two_factor

For more information, see the Custom Domains documentation.

Security Best Practices

Secret Management

Never commit secrets: Use environment variables for all sensitive data
Generate strong secrets: Use openssl rand -hex 64 to generate secure random values
Rotate secrets regularly: Update JWT secrets, session secrets, and encryption keys periodically
Use separate secrets: Never reuse the same secret value for different purposes

Encryption Keys

# Generate strong encryption keys
openssl rand -hex 64  # For JWT_SECRET
openssl rand -hex 64  # For SESSION_SECRET
openssl rand -hex 64  # For STORAGE_ENCRYPTION_KEY

Authentication Policies

Default deny: Always start with a default deny policy
Least privilege: Grant minimum required access
Two-factor for sensitive resources: Require 2FA for admin panels and sensitive operations
Network restrictions: Use network-based policies for internal services
Regular audits: Review access control rules and user permissions regularly

Database Security

Use strong passwords: Generate complex database passwords
Limit permissions: Database user should only have access to Authelia database
Enable SSL/TLS: Use encrypted connections to database (when supported)
Regular backups: Implement automated database backup strategy

Session Management

Short session lifetimes: Balance security with user experience
Enable inactivity timeout: Automatically logout inactive users
Use Redis for sessions: Never use file-based session storage in production
Secure Redis: Always use authentication for Redis
Redis over TLS: Enable TLS for Redis connections when possible

Rate Limiting

Configure rate limiting to prevent brute-force attacks:

regulation:
  max_retries: 3
  find_time: 120  # 2 minutes
  ban_time: 300   # 5 minutes

Monitoring and Logging

Application Logs

Monitor Authelia logs through Klutch.sh dashboard:

Authentication attempts (successful and failed)
Access control decisions
Configuration changes
Error messages and warnings

Health Checks

Authelia provides a health check endpoint:

curl https://authelia-abc123.klutch.sh/api/health

Expected response:

{
  "status": "UP"
}

Metrics and Monitoring

For production deployments:

Monitor authentication success/failure rates
Track session creation and expiration
Monitor Redis connection health
Monitor database connection health
Set up alerts for failed authentication attempts
Track response times and latency

Backup and Recovery

Configuration Backup

Regularly backup your /config volume:

configuration.yml - Main configuration
users.yml - User database (if using file-based auth)
Encryption keys and secrets

Database Backup

Implement regular database backups:

MySQL:

mysqldump -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASSWORD authelia > authelia-backup-$(date +%Y%m%d).sql

PostgreSQL:

pg_dump -h $POSTGRES_HOST -U $POSTGRES_USER authelia > authelia-backup-$(date +%Y%m%d).sql

Disaster Recovery

To restore Authelia:

Deploy new Authelia instance with same configuration
Restore database from backup
Restore configuration files from backup
Use same encryption keys and secrets
Verify all applications can authenticate

Troubleshooting

Common Issues

Issue: Cannot access Authelia portal

Check that the app is running in Klutch.sh dashboard
Verify port 9091 is correctly configured
Check application logs for errors
Verify DNS settings if using custom domain

Issue: Authentication fails with “Invalid credentials”

Verify user exists in users.yml or LDAP
Check password hash is correct
Review authentication backend configuration
Check LDAP connection if using LDAP

Issue: Redis connection errors

Verify Redis hostname and port
Check Redis password is correct
Ensure Redis instance is running
Test Redis connectivity: redis-cli -h $REDIS_HOST -p $REDIS_PORT -a $REDIS_PASSWORD ping

Issue: Database connection errors

Verify database credentials
Check database hostname and port
Ensure database exists and user has permissions

Test database connectivity:

mysql -h $MYSQL_HOST -u $MYSQL_USER -p$MYSQL_PASSWORD -e "USE authelia;"

Issue: Session not persisting

Verify Redis is properly configured
Check session domain matches your application domain
Verify session secrets are set correctly
Check browser cookies are enabled

Issue: 2FA enrollment fails

Verify SMTP configuration for email delivery
Check notifier logs for errors
Test SMTP connectivity
Verify user email address is correct

Debug Mode

Enable debug logging for troubleshooting:

log:
  level: debug
  format: text

Or via environment variable:

AUTHELIA_LOG_LEVEL=debug

Testing Configuration

Before deploying to production, validate your configuration:

docker run --rm -v /path/to/config:/config authelia/authelia:latest authelia validate-config /config/configuration.yml

Scaling and High Availability

Horizontal Scaling

Authelia supports horizontal scaling for high availability:

Deploy multiple Authelia instances: Use Klutch.sh to create multiple replicas
Shared Redis: All instances must use the same Redis server
Shared Database: All instances must connect to the same database
Load balancing: Klutch.sh handles load balancing automatically
Session affinity: Not required due to Redis session storage

Performance Optimization

Use external Redis: Dedicated Redis instance improves performance
Database connection pooling: Configure appropriate connection limits
Enable caching: Use Redis for caching authentication decisions
CDN for static assets: Serve portal assets via CDN
Monitor resource usage: Scale based on CPU/memory metrics

Getting Started Example

After deployment, test your Authelia instance:

Step 1: Access the Portal

Navigate to your Authelia URL (e.g., https://authelia-abc123.klutch.sh)

Step 2: Create First User

If using file-based authentication, create your first admin user:

# Generate password hash
docker run --rm authelia/authelia:latest authelia crypto hash generate argon2 --password 'MySecurePassword123!'

# Add to users.yml in /config volume

Step 3: Test Authentication

Navigate to Authelia portal
Enter username and password
Complete 2FA enrollment (if required)
Verify you can access protected resources

Step 4: Configure Access Rules

Update configuration.yml with your application domains and policies:

access_control:
  rules:
    - domain: "myapp.klutch.sh"
      policy: two_factor

Step 5: Integrate with Applications

Follow the integration guide to protect your applications with Authelia.

Advanced Configuration

LDAP/Active Directory Integration

Connect Authelia to your existing directory services:

authentication_backend:
  ldap:
    url: ldaps://ldap.example.com:636
    base_dn: dc=example,dc=com
    username_attribute: uid
    additional_users_dn: ou=users
    users_filter: (&({username_attribute}={input})(objectClass=person))
    additional_groups_dn: ou=groups
    groups_filter: (&(member={dn})(objectClass=groupOfNames))
    group_name_attribute: cn
    mail_attribute: mail
    display_name_attribute: displayName
    user: cn=admin,dc=example,dc=com
    password: ${LDAP_PASSWORD}

OpenID Connect Provider

Configure Authelia as an OpenID Connect provider:

identity_providers:
  oidc:
    hmac_secret: ${OIDC_HMAC_SECRET}
    issuer_private_key: ${OIDC_ISSUER_PRIVATE_KEY}

    clients:
      - id: myapp
        description: My Application
        secret: ${OIDC_CLIENT_SECRET}
        public: false
        authorization_policy: two_factor
        redirect_uris:
          - https://myapp.klutch.sh/oauth2/callback
        scopes:
          - openid
          - profile
          - email
          - groups

Duo Push Integration

Enable Duo for push-based 2FA:

duo_api:
  hostname: ${DUO_API_HOSTNAME}
  integration_key: ${DUO_INTEGRATION_KEY}
  secret_key: ${DUO_SECRET_KEY}

Migration and Updates

Updating Authelia

To update to a new Authelia version:

Update the image tag in your Dockerfile: FROM authelia/authelia:4.39
Commit and push changes to GitHub
Redeploy the application in Klutch.sh
Monitor logs for any migration messages
Test authentication after update

Configuration Migration

When upgrading between major versions:

Review Authelia changelog for breaking changes
Update configuration schema if required
Test in staging environment first
Backup database before production update
Plan for rollback if needed

Cost Optimization

Resource Sizing

Authelia resource requirements:

CPU: 0.5-1 vCPU for small deployments (< 100 users)
Memory: 512MB-1GB for typical workloads
Storage: 1GB for configuration, 5-10GB for SQLite (if used)
Database: Size based on user count and session history

Cost-Saving Tips

Use external Redis/Database for multiple Authelia instances (shared resources)
Enable session expiration and cleanup to reduce database size
Use SQLite for development/testing (not production)
Monitor and adjust resource allocation based on actual usage
Scale down during low-traffic periods

Production Deployment Checklist

Before going to production: