Deploying Conduit
Introduction
Conduit is a lightweight, fast, and feature-rich Matrix homeserver written in Rust. It provides a modern alternative to Synapse, the reference implementation of the Matrix protocol, while offering significantly better performance characteristics and lower resource requirements.
Matrix is an open standard for decentralized, real-time communication. It enables interoperability between different messaging platforms, allowing users on one Matrix homeserver to communicate seamlessly with users on any other Matrix homeserver—similar to how email works across different providers.
What Makes Conduit Special:
Performance-First Design: Written in Rust with a focus on efficiency, Conduit uses dramatically less memory and CPU compared to Synapse while handling similar workloads.
Simple Deployment: Minimal dependencies and straightforward configuration make deployment accessible to developers of all skill levels.
Federation: Full support for Matrix federation, enabling your users to chat with anyone on any Matrix network.
Feature Complete: Supports direct messages, group chats, encryption, file sharing, and all essential messaging features.
SQLite Support: Can use SQLite for simple deployments or PostgreSQL for scaling to large installations.
Lightweight: Designed to run efficiently on modest hardware, from single-board computers to dedicated servers.
Active Development: Regularly updated with new features and performance improvements.
Community Focus: Part of the larger Matrix ecosystem with strong community support and integrations.
Conduit lets you run your own messaging infrastructure with complete control over data and privacy. Unlike proprietary messaging platforms, there’s no vendor lock-in—your data remains yours, and users can interoperate with the broader Matrix network.
This guide walks you through deploying Conduit on Klutch.sh using Docker. You’ll learn how to configure the server with persistent storage, set up optional database backends, implement security measures, optimize performance, and troubleshoot common deployment issues.
Prerequisites
Before deploying Conduit to Klutch.sh, ensure you have:
- A Klutch.sh account with dashboard access
- A GitHub account for repository hosting
- Docker installed locally for testing (optional but recommended)
- Basic understanding of Matrix protocol and chat servers
- A domain name for your homeserver (required for federation)
- Understanding of SSL/TLS certificates
- Basic knowledge of networking and firewall configuration
Understanding Conduit Architecture
Technology Stack
Conduit is built on modern technologies optimized for performance:
Backend:
- Rust programming language for memory safety and performance
- Tokio async runtime for high concurrency
- Rocksdb or SQLite for data persistence
- HTTP/2 support for efficient communication
- Full Matrix protocol implementation
Storage:
- SQLite (default, good for small to medium deployments)
- RocksDB (optimized for high-concurrency scenarios)
- PostgreSQL (alternative database backend)
Communication:
- WebSocket support for real-time messaging
- HTTP API for client-server communication
- Server-to-server federation protocol
- End-to-end encryption (E2EE) support
Core Components
Matrix Homeserver: The central server that handles user accounts, messages, and room management
Client-Server API: Enables chat applications to connect and communicate
Server-Server Federation: Allows your homeserver to communicate with other Matrix servers
Room Management: Handles creation, permissions, and message persistence
User Management: Account creation, authentication, and profile management
Encryption: End-to-end encryption for private conversations
Installation and Setup
Step 1: Create Your Project Directory
Start with a dedicated directory for your Conduit deployment:
mkdir conduit-deploymentcd conduit-deploymentgit initStep 2: Create Directory Structure
Set up the necessary directories:
mkdir -p data configYour project structure will look like:
conduit-deployment/├── Dockerfile├── docker-entrypoint.sh├── conduit.toml├── .dockerignore├── .gitignore└── data/ └── (persistent storage)Step 3: Create the Dockerfile
Create a Dockerfile in your project root:
# Use official Rust image for buildingFROM rust:latest as builder
WORKDIR /build
# Clone Conduit repositoryRUN git clone --depth 1 https://github.com/conduit-rs/conduit.git .
# Build Conduit in release modeRUN cargo build --release
# Use minimal runtime imageFROM debian:bookworm-slim
# Install runtime dependenciesRUN apt-get update && apt-get install -y --no-install-recommends \ ca-certificates \ curl \ libssl3 \ && rm -rf /var/lib/apt/lists/*
# Create application userRUN useradd -m -u 1000 conduit
# Copy built binary from builderCOPY --from=builder /build/target/release/conduit /usr/local/bin/conduit
# Set working directoryWORKDIR /var/lib/conduit
# Create data directoryRUN mkdir -p /var/lib/conduit/data && \ chown -R conduit:conduit /var/lib/conduit
# Copy configuration templateCOPY conduit.toml /var/lib/conduit/conduit.toml
# Switch to non-root userUSER conduit
# Expose Matrix portEXPOSE 6167
# Health checkHEALTHCHECK --interval=30s --timeout=10s --start-period=60s --retries=3 \ CMD curl -f http://localhost:6167/_matrix/client/versions || exit 1
# Start ConduitCMD ["conduit"]Step 4: Create Configuration File
Create conduit.toml with basic configuration:
[global]# Server name - should match your domainserver_name = "example.com"
# Address to bind to (inside container)address = "0.0.0.0"port = 6167
# Database settingsdatabase_backend = "sqlite"database_path = "/var/lib/conduit/data"
# TLS configuration (handled by Klutch.sh)# Disable internal TLS since Klutch.sh handles SSL/TLSallow_insecure_origin = true
# Maximum upload size (in bytes)max_request_size = 20_000_000# 20MB
# Logging levellog = "info"
# Optional: Rate limiting# Set to 0 to disablerequest_timeout_ms = 30000
# Connection settingsmax_concurrent_requests = 1000
[services]# Optional: Admin API (require auth)allow_admin_api = false
# Optional: Outbound proxy# outbound_proxy = ""
[features]# Enable registrationregistration_required = true
# Require approval for new registrations (admin only)registration_token_required = false
# Allow guest accessallow_guest_access = falseStep 5: Create Entrypoint Script
Create docker-entrypoint.sh for initialization:
#!/bin/bashset -e
echo "Starting Conduit initialization..."
# Set server name from environment variable if providedif [ ! -z "$SERVER_NAME" ]; then echo "Configuring server name: $SERVER_NAME" sed -i "s/server_name = \"example.com\"/server_name = \"$SERVER_NAME\"/g" /var/lib/conduit/conduit.tomlfi
# Set database backend if providedif [ ! -z "$DATABASE_BACKEND" ]; then echo "Setting database backend: $DATABASE_BACKEND" sed -i "s/database_backend = \"sqlite\"/database_backend = \"$DATABASE_BACKEND\"/g" /var/lib/conduit/conduit.tomlfi
# Configure PostgreSQL if neededif [ "$DATABASE_BACKEND" = "postgresql" ]; then if [ ! -z "$DATABASE_URL" ]; then echo "Configuring PostgreSQL connection" sed -i "s|database_path = \"/var/lib/conduit/data\"|database_url = \"$DATABASE_URL\"|g" /var/lib/conduit/conduit.toml fifi
# Configure max file upload size if providedif [ ! -z "$MAX_FILE_SIZE" ]; then echo "Setting max file size: $MAX_FILE_SIZE" sed -i "s/max_request_size = 20_000_000/max_request_size = $MAX_FILE_SIZE/g" /var/lib/conduit/conduit.tomlfi
# Ensure data directory exists and has correct permissionsmkdir -p /var/lib/conduit/datachown -R conduit:conduit /var/lib/conduit
echo "Conduit initialization complete. Starting server..."
# Execute the main commandexec "$@"Make it executable:
chmod +x docker-entrypoint.shStep 6: Create .dockerignore
Create .dockerignore to exclude unnecessary files:
.git.gitignore.env.env.local*.log.DS_Store.vscode.ideaREADME.mddocs/target/data/Step 7: Create .gitignore
Create .gitignore to prevent committing sensitive files:
# Environment.env.env.local.env.production
# Build artifactstarget/*.o*.so*.dylib*.dll
# Logs*.loglogs/
# Datadata/*.db
# OS.DS_StoreThumbs.db
# IDE.vscode/.idea/*.swp*.swo
# Configuration with secretsconduit.toml.localStep 8: Local Testing (Optional)
Test your Conduit setup locally:
# Build the imagedocker build -t conduit-test .
# Run Conduit locallydocker run -d \ --name conduit-server \ -p 6167:6167 \ -e SERVER_NAME=localhost:6167 \ -v $(pwd)/data:/var/lib/conduit/data \ conduit-test
# Wait for startupsleep 10
# Test the health endpointcurl http://localhost:6167/_matrix/client/versions
# View logsdocker logs -f conduit-server
# Cleanupdocker stop conduit-serverdocker rm conduit-serverStep 9: Commit to GitHub
Push your configuration to GitHub:
git add Dockerfile docker-entrypoint.sh conduit.toml .dockerignore .gitignoregit commit -m "Add Conduit Matrix homeserver Docker configuration"git branch -M maingit remote add origin https://github.com/yourusername/conduit-deployment.gitgit push -u origin mainDeploying to Klutch.sh
Now let’s deploy Conduit to Klutch.sh with proper configuration and persistent storage.
Deployment Steps
-
Access Klutch.sh Dashboard
Navigate to klutch.sh/app and sign in with your GitHub account.
-
Create a New Project
In the Projects section, click “Create Project” and name it something like “Conduit Matrix Server” or “Chat Infrastructure”.
-
Create a New App
Within your project, click “Create App” to begin configuring your Conduit deployment.
-
Connect Your Repository
- Select GitHub as your Git source
- Choose your repository with the Conduit Dockerfile
- Select the branch to deploy (typically
main)
Klutch.sh will automatically detect the Dockerfile in your repository root.
-
Configure Traffic Settings
- Traffic Type: Select HTTP (Conduit serves Matrix protocol over HTTP)
- Internal Port: Set to
6167(Conduit’s default listening port)
-
Configure Environment Variables
Add the following environment variables to configure your Conduit instance:
Server Configuration:
Terminal window # Your homeserver domain name (required for federation)SERVER_NAME=matrix.example.com# Description for your serverSERVER_DESCRIPTION="My Conduit Matrix Server"# Trusted proxies (Klutch.sh)TRUSTED_SERVERS=example-app.klutch.shDatabase Configuration:
Terminal window # Database backend: sqlite or postgresqlDATABASE_BACKEND=sqlite# For PostgreSQL (if using external database):DATABASE_URL=postgresql://conduit_user:password@your-db-host:5432/conduitServer Behavior:
Terminal window # Maximum upload size in bytesMAX_FILE_SIZE=20000000# 20MB# Require registration approvalREGISTRATION_TOKEN_REQUIRED=false# Allow guest accessALLOW_GUEST_ACCESS=false# Logging level: off, error, warn, info, debug, traceLOG_LEVEL=info# Maximum concurrent requestsMAX_CONCURRENT_REQUESTS=1000# Request timeout in millisecondsREQUEST_TIMEOUT_MS=30000Optional: Admin Configuration:
Terminal window # Enable admin API (requires authentication)ALLOW_ADMIN_API=false# Admin token (if enabling admin API)ADMIN_TOKEN=your-secure-admin-tokenPerformance Tuning:
Terminal window # Worker threads (leave blank for auto-detection)# Set to number of CPU cores for optimal performanceCONDUIT_WORKERS=4# Connection pool sizeCONDUIT_CONNECTION_POOL_SIZE=32Security Note:
- Generate strong, unique values for admin tokens
- Keep
REGISTRATION_TOKEN_REQUIRED=truefor controlled growth - Never commit environment variables to Git
- Use strong passwords for any external databases
-
Configure Persistent Storage
Conduit needs persistent storage for data:
Volume 1 - Data Storage:
- Mount Path:
/var/lib/conduit/data - Size: 5-20 GB (depends on number of users and messages)
Guidelines for volume size:
- Small instance (< 100 users): 5 GB
- Medium instance (100-500 users): 10 GB
- Large instance (500+ users): 20+ GB
Important: Without persistent storage, all user data, messages, and room state will be lost on container restart.
- Mount Path:
-
Configure Compute Resources
Choose appropriate resources based on expected users:
Small Deployment (< 50 users):
- CPU: 1 core
- RAM: 1 GB
- Suitable for: Testing, small communities
Medium Deployment (50-200 users):
- CPU: 2 cores
- RAM: 2 GB
- Suitable for: Team messaging, medium communities
Large Deployment (200-1000 users):
- CPU: 4 cores
- RAM: 4 GB
- Suitable for: Organizations, active communities
Enterprise (1000+ users):
- CPU: 8+ cores
- RAM: 8+ GB
- Suitable for: Large organizations, public servers
You can scale based on actual usage patterns.
-
Deploy the Application
Click “Create” to start the deployment. Klutch.sh will:
- Clone your repository
- Build the Docker image (Rust compilation takes ~10-15 minutes)
- Configure environment variables
- Set up persistent storage
- Start the Conduit container
- Assign a public URL (e.g.,
example-app.klutch.sh) - Configure automatic HTTPS with SSL certificates
Initial deployment may take 15-20 minutes due to Rust compilation.
-
Monitor Deployment Progress
Track the deployment:
- Go to the Deployments tab
- View real-time build logs (Rust build output is verbose)
- Wait for status to show “Running”
- Note that build times are longer than typical applications due to Rust compilation
-
Configure Your Domain
Add your custom domain to Klutch.sh:
- In Klutch.sh dashboard, go to Domains
- Click “Add Custom Domain”
- Enter your domain (e.g.,
matrix.example.com) - Update DNS with CNAME record pointing to
example-app.klutch.sh - Wait for DNS propagation and SSL certificate provisioning
Update Conduit Configuration:
- Redeploy with updated
SERVER_NAMEenvironment variable - Point to your custom domain:
SERVER_NAME=matrix.example.com
-
Verify Installation
After deployment, verify Conduit is working:
-
Check the Matrix client API:
Terminal window curl https://example-app.klutch.sh/_matrix/client/versionsShould return JSON with supported client API versions.
-
Check the server info:
Terminal window curl https://example-app.klutch.sh/_matrix/federation/v1/versionShould return server information.
-
Test from a Matrix client:
- Use a client like Element, FluffyChat, or Beeper
- Set custom homeserver:
https://matrix.example.com - Create account on your server
- Verify login works
-
Check application logs for any errors
-
Database Configuration
Conduit comes with SQLite as the default database, which works well for most deployments. For larger installations, consider PostgreSQL.
SQLite (Default)
Pros:
- No external dependencies
- Easy to backup
- Low overhead
- Suitable for thousands of users
Cons:
- Not ideal for extremely high concurrency
- Limited scaling options
Configuration:
DATABASE_BACKEND=sqlite# Data stored in /var/lib/conduit/data directoryPostgreSQL
For deployments with thousands of users or very high message throughput, PostgreSQL provides better performance.
Setup:
Use an external PostgreSQL service or deploy on Klutch.sh:
Recommended Providers:
Configuration:
DATABASE_BACKEND=postgresqlDATABASE_URL=postgresql://conduit_user:secure_password@host:5432/conduitCreate Database and User:
CREATE DATABASE conduit;CREATE USER conduit_user WITH PASSWORD 'secure_password';GRANT ALL PRIVILEGES ON DATABASE conduit TO conduit_user;Conduit automatically creates required tables and indexes on first run.
Getting Started with Conduit
Joining Your Server
Using a Matrix Client:
-
Download a client:
- Element (web, mobile, desktop)
- FluffyChat (mobile-focused)
- Beeper (unified messaging)
-
Configure custom homeserver:
- Instead of using the default homeserver, select “Sign in with custom URL”
- Enter your Conduit server URL:
https://matrix.example.com
-
Create account:
- Choose username and password
- Verify email (optional but recommended)
- Start using Matrix
Creating Rooms
Rooms are the core of Matrix—they’re like channels or group chats.
Creating a Room:
- Click the ”+” button or “Create Room”
- Enter room name (e.g., “engineering”)
- Set room visibility (public or private)
- Optionally set topic/description
- Add initial members
- Create
Room Features:
- Direct messages (one-on-one chats)
- Group chats (multiple members)
- Public rooms (discoverable, anyone can join)
- Private rooms (invitation-only)
- Encrypted rooms (end-to-end encryption)
User Management
Creating Users:
Users can register themselves if registration is enabled. Admins can also manage users through admin endpoints.
Admin API (if enabled):
# Create usercurl -X POST \ -H "Content-Type: application/json" \ -d '{"user_id":"@alice:matrix.example.com","password":"secure"}' \ https://matrix.example.com/_matrix/client/r0/admin/users/@alice:matrix.example.com/passwordUser Settings:
- Username and display name
- Avatar/profile picture
- Status message
- Device management
- Session management
Federation with Other Servers
Matrix federation allows your users to chat with people on any Matrix homeserver.
How Federation Works:
- User on your server sends message to user on another server
- Your server looks up the other server’s address
- Establishes secure connection to other server
- Message is delivered
- Other server notifies the recipient
Verify Federation:
Check if your server is reachable:
# From another server or online toolcurl https://matrix.example.com/_matrix/federation/v1/versionShould return your server information.
Connect with Other Users:
In your Matrix client, invite users from other servers:
- Format:
@username:other-server.com - Example:
@alice:matrix.org(on public matrix.org server)
Security Best Practices
Access Control
Registration Control:
# Require registration approvalREGISTRATION_TOKEN_REQUIRED=true
# Disable guest accessALLOW_GUEST_ACCESS=false
# Require email verificationEMAIL_VERIFICATION_REQUIRED=trueAdmin Endpoints:
# Enable admin API for managementALLOW_ADMIN_API=true
# Use strong admin tokenADMIN_TOKEN=$(openssl rand -base64 32)Encryption
Conduit fully supports end-to-end encryption (E2EE). Users can create encrypted rooms where messages are only readable by participants.
E2EE Features:
- Automatic encryption for private rooms
- Device verification for security
- Key backup for recovery
- Cross-signing for trust
Enable by default in client settings.
Transport Security
HTTPS Requirements:
- All Matrix communication uses HTTPS
- Klutch.sh provides automatic SSL certificates
- Server-to-server federation uses HTTPS
- Verify custom domain has valid certificate
Certificate Pinning (advanced):
For high-security deployments, implement certificate pinning in clients.
Data Privacy
Retention Policies:
Configure message retention:
# In conduit.toml# Keep all messages (default)# Or set specific retention times
# Database encryption at rest (depends on storage provider)Backups:
Regular backups are essential:
# Backup SQLite databasecp -r /var/lib/conduit/data/db /backups/conduit-$(date +%Y%m%d).db
# Backup PostgreSQL databasepg_dump postgresql://conduit_user:password@host/conduit | gzip > /backups/conduit-$(date +%Y%m%d).sql.gzUser Privacy:
Matrix is designed with privacy in mind:
- Users control their profile visibility
- Room access controlled by members
- Encrypted rooms prevent eavesdropping
- Users can delete accounts and messages
Regular Maintenance
Update Conduit:
Regularly update to get security patches:
- Check for updates: Monitor Conduit releases
- Update Dockerfile to new version
- Test in staging environment
- Deploy update through Klutch.sh
- Monitor logs for issues
Verify Security:
- Review Matrix spec for security implications
- Monitor Matrix security advisories
- Keep Rust dependencies updated
- Test encryption functionality
- Verify federation security
Performance Optimization
Resource Allocation
CPU:
Conduit is efficient with CPU. Allocate based on user count:
- < 100 users: 1 core sufficient
- 100-500 users: 2 cores recommended
- 500-1000 users: 4 cores recommended
- 1000+ users: 8+ cores
Memory:
Memory usage depends on:
- Number of rooms
- Number of users
- Message caching
- Connection count
General guidelines:
- Small deployments: 1-2 GB RAM
- Medium deployments: 2-4 GB RAM
- Large deployments: 4-8+ GB RAM
Database:
SQLite works efficiently up to several thousand users. For larger deployments:
- Switch to PostgreSQL
- Use dedicated database server
- Configure connection pooling
- Regular vacuuming
Caching
Conduit efficiently caches:
- User profiles
- Room state
- Event data
- Federation information
Caching is automatic and requires no configuration.
Network Optimization
WebSocket Connections:
Conduit supports WebSocket for efficient real-time messaging. Clients automatically use WebSocket when available.
Compression:
Enable HTTP compression in reverse proxy (not needed if using Klutch.sh’s reverse proxy).
Connection Management:
MAX_CONCURRENT_REQUESTS=1000REQUEST_TIMEOUT_MS=30000Tune based on your deployment’s needs.
Troubleshooting
Issue 1: Server Won’t Start
Symptoms: Container exits immediately or shows errors on startup
Solutions:
-
Check Logs:
- Go to Klutch.sh dashboard
- View application logs
- Look for configuration or startup errors
-
Verify Configuration:
- Check
SERVER_NAMEis set correctly - Verify
DATABASE_BACKENDis valid - Ensure
/var/lib/conduit/datais writable
- Check
-
Database Issues:
- For PostgreSQL: verify connection URL
- Ensure database exists
- Check user permissions
-
Port Configuration:
- Verify port 6167 is exposed
- Check no other service uses this port
Issue 2: Federation Not Working
Symptoms: Messages don’t reach other servers, federation fails
Solutions:
-
Verify Public DNS:
Terminal window dig matrix.example.comnslookup matrix.example.comShould return correct IP address.
-
Check Federation Port:
- Matrix federation uses port 8448 (HTTPS)
- Klutch.sh handles this through standard HTTPS (443)
- Verify custom domain is configured
-
Test Federation:
Terminal window curl https://matrix.example.com/_matrix/federation/v1/versionShould return JSON with server information.
-
SSL Certificate:
- Verify valid certificate installed
- Check certificate is not self-signed for federation
- Klutch.sh automatically provisions valid certificates
Issue 3: Can’t Create Account
Symptoms: Registration fails, “registration disabled” errors
Solutions:
-
Check Registration Settings:
Terminal window # Verify registration is enabledREGISTRATION_TOKEN_REQUIRED=false# For token-based registrationREGISTRATION_TOKEN_REQUIRED=true -
Admin Token:
- If token required, provide token during registration
- Generate token through admin API
-
Database Issues:
- Verify database connection works
- Check database has free space
- Verify user creation permissions
Issue 4: Slow Message Delivery
Symptoms: Messages delayed, slow real-time updates
Solutions:
-
Check Resource Usage:
- Monitor CPU usage in Klutch.sh
- Check memory usage
- Look for bottlenecks
-
Upgrade Resources:
- Increase CPU cores
- Increase RAM
- Reduce user load or increase server capacity
-
Database Performance:
- For SQLite: ensure disk is fast
- For PostgreSQL: check query performance
- Monitor database connections
-
Connection Limits:
- Increase
MAX_CONCURRENT_REQUESTSif needed - Check for connection pool exhaustion
- Increase
Issue 5: High Memory Usage
Symptoms: Server consuming excessive memory, OOM errors
Solutions:
-
Identify Memory Leaks:
- Monitor memory usage over time
- Check for rapidly growing memory
- Review Conduit logs
-
Reduce User Load:
- Limit concurrent users
- Reduce number of rooms
- Enable message retention limits
-
Upgrade Resources:
- Allocate more RAM
- Upgrade to larger instance
- Scale horizontally if needed
-
Database Tuning:
- Optimize database queries
- Reduce cache size if needed
- Monitor database memory usage
Issue 6: TLS/Certificate Errors
Symptoms: “Certificate invalid”, federation fails, security warnings
Solutions:
-
Verify Certificate:
Terminal window curl -v https://matrix.example.com/_matrix/client/versions# Check certificate details -
DNS Configuration:
- Verify DNS records are correct
- Wait for propagation if recently changed
- Check CNAME points to Klutch.sh domain
-
Klutch.sh SSL:
- Give Klutch.sh time to provision certificate
- May take 5-10 minutes after DNS updates
- Check for ACME renewal issues
-
Client Configuration:
- Ensure client trusts certificate authority
- Update client certificates if using self-signed (not recommended)
- Clear client cache
Issue 7: Database Corruption
Symptoms: “Database locked”, corruption errors, failed queries
Solutions:
-
For SQLite:
- Stop Conduit server
- Check database file integrity:
sqlite3 data/conduit.db "PRAGMA integrity_check;" - Restore from backup if corrupted
-
For PostgreSQL:
- Check PostgreSQL logs for corruption
- Run
REINDEXif needed - Contact database provider
-
Prevent Corruption:
- Use persistent volumes for reliability
- Regular backups
- Proper shutdown procedures
- Avoid force-killing containers
Issue 8: Room/Message Issues
Symptoms: Can’t create rooms, missing messages, room join failures
Solutions:
-
Check Permissions:
- Verify user has creation permissions
- Check room access controls
- Verify user not banned
-
Database Issues:
- Ensure database has free space
- Check user quota not exceeded
- Verify room state consistency
-
Clear Cache:
- Restart server to clear in-memory cache
- Force clients to resync
- Rebuild room state if needed
Issue 9: Client Connection Issues
Symptoms: Clients can’t connect, “connection refused”, timeouts
Solutions:
-
Verify Server Running:
- Check app status in Klutch.sh
- View application logs
- Verify container is healthy
-
Check Homeserver URL:
- Verify correct URL in client:
https://matrix.example.com - Ensure protocol is HTTPS
- Check custom domain if using
- Verify correct URL in client:
-
Firewall/Network:
- Verify ports are open
- Check ISP isn’t blocking connections
- Try from different network
-
Client Issues:
- Clear client cache and cookies
- Update to latest client version
- Try different client to isolate issue
Issue 10: Admin API Issues
Symptoms: Admin commands fail, authorization errors
Solutions:
-
Enable Admin API:
Terminal window ALLOW_ADMIN_API=true -
Verify Admin Token:
- Ensure token is correctly set
- Token must be sent in Authorization header
- Verify header format:
Authorization: Bearer TOKEN
-
Check Permissions:
- Verify admin token has necessary permissions
- Some operations require full admin rights
- Review operation logs
Custom Domains
Using a custom domain is essential for Matrix federation.
Step 1: Add Domain in Klutch.sh
- Go to your Conduit app in Klutch.sh dashboard
- Navigate to Domains
- Click “Add Custom Domain”
- Enter your domain (e.g.,
matrix.example.com) - Save
Step 2: Configure DNS
Update your domain provider:
Type: CNAMEName: matrix (if subdomain) or @ (for root)Value: example-app.klutch.shTTL: 3600Step 3: Update Conduit Configuration
Set the server name environment variable:
SERVER_NAME=matrix.example.comRedeploy the application for the change to take effect.
Step 4: Verify Setup
-
Wait for DNS propagation (up to 1 hour)
-
Test DNS:
Terminal window nslookup matrix.example.com -
Verify SSL certificate (wait a few minutes for provisioning)
-
Test federation:
Terminal window curl https://matrix.example.com/_matrix/federation/v1/version -
Update client homeserver URL
Production Best Practices
Backup Strategy
What to Backup:
- Database (SQLite or PostgreSQL)
- User data and keys
- Configuration files
Backup Schedule:
- Daily: Database backup
- Weekly: Full system backup
- Monthly: Archival backup
Backup Commands:
# SQLite backupcp -r /var/lib/conduit/data /backups/conduit-data-$(date +%Y%m%d)
# PostgreSQL backuppg_dump DATABASE_URL | gzip > /backups/conduit-$(date +%Y%m%d).sql.gz
# Store in safe location# Consider cloud storage backupRestore Procedures:
- Document restoration steps
- Test recovery monthly
- Keep offline backup copies
- Verify backup integrity
Monitoring and Alerting
Key Metrics:
- CPU and memory usage
- Database performance
- Message throughput
- User count
- Disk space
- Error rates
Alerts:
- High CPU (> 80% sustained)
- High memory (> 90%)
- Disk space low (< 10% free)
- Database errors
- Federation failures
Scaling Strategies
Vertical Scaling (recommended for most):
- Increase CPU cores
- Increase RAM
- Upgrade storage
- Improve database performance
When to Scale:
- CPU consistently > 70%
- Memory > 80%
- Response times increasing
- Database getting slow
Horizontal Scaling (for very large deployments):
- Multiple Conduit instances
- Load balancer
- Shared database (PostgreSQL)
- Shared media storage
Security Maintenance
Regular Tasks:
Weekly:
- Monitor error logs
- Check federation status
- Verify TLS certificates
Monthly:
- Security audit
- Access control review
- Backup verification
Quarterly:
- Major updates
- Security assessment
- Performance review
Annually:
- Disaster recovery test
- Capacity planning
- Strategy evaluation
Additional Resources
- Conduit Official Website
- Conduit GitHub Repository
- Matrix Protocol Official Site
- Matrix Specification
- Element Matrix Client
- Matrix Clients List
- Klutch.sh Official Website
- Klutch.sh Dashboard
- Klutch.sh Documentation
- Klutch.sh Custom Domains Guide
Conclusion
Deploying Conduit on Klutch.sh gives you a lightweight, efficient Matrix homeserver with complete control over your messaging infrastructure. You’ve learned how to build a production-ready Dockerfile with multi-stage compilation, configure the server with persistent storage for user data and messages, set up optional PostgreSQL for scaling, implement security best practices for user authentication and encryption, optimize performance for your user base, troubleshoot common deployment issues, and configure federation with the broader Matrix network.
Conduit’s Rust implementation provides significant advantages in resource efficiency compared to other Matrix homeservers. Your deployment can handle thousands of users while consuming minimal server resources.
With Klutch.sh’s straightforward deployment, you can focus on building your community rather than managing infrastructure. Your server is running on reliable infrastructure with automatic HTTPS, scalable resources, and global distribution.
Matrix federation enables your users to communicate with the broader Matrix network—no walled garden, no vendor lock-in. Your users can chat with anyone on any Matrix homeserver, just like email works across providers.
Start small, monitor your usage patterns, and scale as your community grows. Conduit’s lightweight design means you can provide high-quality messaging infrastructure without breaking the bank.
For questions, community support, or to learn more about the Matrix protocol, check out the Conduit website, Matrix specification, and active community forums.