Deploying a Cloudlog App

Cloudlog is a powerful, open-source web-based amateur radio logging application designed for radio operators to manage QSO (contact) records, organize digital mode communications, track DX operations, participate in contests, and maintain comprehensive radio operation logs accessible from any device. Built with a modern web interface, Cloudlog enables radio enthusiasts to log contacts in real-time, manage multiple bands and modes, integrate with digital communication tools, track contest progress, generate reports, and collaborate with other operators—all from a centralized web platform. Whether you’re a casual radio operator maintaining a personal log, an active DX chaser tracking new countries, a contest participant logging thousands of contacts, or a radio club managing shared operations, Cloudlog provides comprehensive features including QSO management, digital mode support, contest integration, award tracking, API connectivity, multi-user access, and detailed reporting.

This comprehensive guide walks through deploying Cloudlog to Klutch.sh using a Dockerfile for reliable, containerized deployment. You’ll learn how to set up Cloudlog with persistent storage for logs and configurations, create a production-ready Dockerfile, configure database connectivity, manage user accounts and permissions, set up contest logging, implement security best practices, configure custom domains, set up monitoring and logging, and troubleshoot common issues. By the end of this guide, you’ll have a production-ready Cloudlog instance running on Klutch.sh’s global infrastructure with automatic HTTPS, optimized performance, and reliable hosting for amateur radio logging operations.

Prerequisites

Docker installed locally for testing (optional but recommended)
Git installed locally and a GitHub account (Klutch.sh uses GitHub as the only git source)
Klutch.sh account with access to the dashboard at klutch.sh/app
Text editor or IDE for code editing (VS Code recommended)
PHP knowledge (helpful but not required—Cloudlog is PHP-based)
Basic networking knowledge: Understanding of HTTP/HTTPS and database connectivity
Amateur radio background (helpful for understanding QSO and contest logging)

Understanding Cloudlog Architecture

Technology Stack

Backend:

PHP framework (CodeIgniter-based)
MySQL or PostgreSQL database for log storage
Apache or Nginx web server
RESTful API for integrations
Session management for user authentication

Frontend:

HTML5/CSS3 responsive web interface
JavaScript for dynamic features
jQuery/Bootstrap for UI components
Real-time update capabilities
Mobile-friendly design

Key Features

QSO Management:

Detailed QSO logging with frequency, mode, signal reports
Multiple band and mode support
Time tracking and duration calculations
Automatic callsign lookup and validation
Quick logging interface
Search and filtering capabilities

Digital Mode Support:

RTTY, PSK, JT65, FT8 mode logging
Digital signal report tracking
Mode-specific parameters
Integration with digital communication tools
Frequency band management
Operating mode statistics

Contest Logging:

Contest framework and rule integration
Contest-specific exchange logging
Scoring calculations
Category tracking
Contest reports and statistics
Multi-band contest support

Award Tracking:

DXCC (DX Country) tracking
Award progress monitoring
Award verification
Badge and certificate generation
Goal setting and milestones
Award statistics and reports

User Management:

User authentication and authorization
Multi-user support
Role-based access control
Station profiles
Operating preferences
Permission management

Reporting and Statistics:

QSO statistics and summaries
Band and mode reports
Country/region tracking
Time-based analysis
Award progress reports
Custom report generation

Project Setup

1. Create Project Directory

Create a project directory for Cloudlog deployment:

mkdir cloudlog-deployment
cd cloudlog-deployment
git init

2. Create Directory Structure

Create necessary directories:

mkdir -p {data,config,logs,backup,scripts}

Resulting project structure:

cloudlog-deployment/
├── Dockerfile
├── entrypoint.sh
├── config/
│   └── default.env
├── scripts/
│   └── init-db.sh
├── data/
│   └── (database files)
├── logs/
│   └── (application logs)
├── .dockerignore
├── .gitignore
└── README.md

3. Create .gitignore File

Create .gitignore to exclude unnecessary files:

.env.local
.env.*.local
*.log
*.swp
.DS_Store
.vscode
.idea
data/
logs/
backup/
tmp/
.php-fpm.conf
.htaccess
.cache
uploads/*

4. Create .dockerignore File

Create .dockerignore to exclude files from Docker build:

.git
.gitignore
*.log
.env.local
data/
logs/
backup/
tmp/
.DS_Store
.vscode
.idea
tests/
README.md
.php-fpm.conf
.cache

Creating a Production Dockerfile

Create a Dockerfile for production deployment:

# === Build Stage ===
FROM composer:2.6 AS builder

WORKDIR /tmp

# Clone Cloudlog repository
RUN git clone https://github.com/magicbug/Cloudlog.git . && \
    git checkout $(git describe --tags --abbrev=0) && \
    composer install --no-dev --optimize-autoloader

# === Production Stage ===
FROM php:8.1-fpm-alpine

WORKDIR /var/www/html

# Install dependencies
RUN apk add --no-cache \
    nginx \
    curl \
    openssl \
    mysql-client \
    postgresql-client \
    zip \
    unzip \
    git \
    fcgi \
    && docker-php-ext-install pdo pdo_mysql pdo_pgsql mbstring json

# Copy PHP-FPM configuration
RUN echo "listen = 127.0.0.1:9000" > /usr/local/etc/php-fpm.conf && \
    echo "listen.backlog = 256" >> /usr/local/etc/php-fpm.conf && \
    echo "[www]" >> /usr/local/etc/php-fpm.conf && \
    echo "user = nobody" >> /usr/local/etc/php-fpm.conf && \
    echo "group = nogroup" >> /usr/local/etc/php-fpm.conf && \
    echo "listen = 127.0.0.1:9000" >> /usr/local/etc/php-fpm.conf

# Copy Nginx configuration
COPY --chown=nobody:nogroup nginx.conf /etc/nginx/nginx.conf

# Copy built application from builder
COPY --from=builder --chown=nobody:nogroup /tmp /var/www/html

# Create app user
RUN addgroup -g 1001 cloudlog && \
    adduser -D -u 1001 -G cloudlog cloudlog && \
    chown -R cloudlog:cloudlog /var/www/html

# Create logs directory
RUN mkdir -p /var/www/html/application/logs && \
    chown -R cloudlog:cloudlog /var/www/html/application/logs

# Copy entrypoint script
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.sh

# Health check
HEALTHCHECK --interval=30s --timeout=10s --start-period=30s --retries=3 \
    CMD curl -f http://localhost:8080/health || exit 1

# Expose port
EXPOSE 8080

# Set user
USER cloudlog

# Start services
CMD ["/entrypoint.sh"]

Dockerfile Explanation

Build stage: Uses Composer to install Cloudlog dependencies
Production stage: Lightweight Alpine PHP-FPM runtime with minimal dependencies
Web server: Nginx for reverse proxy
Database support: MySQL and PostgreSQL drivers
Data persistence: /var/www/html for application and logs
Non-root user: Runs as cloudlog user for security
Health checks: Automatic container health monitoring
Multi-stage build: Reduces final image size by excluding build tools

Create Nginx Configuration

Create nginx.conf for web server configuration:

user nobody;
worker_processes auto;
pid /var/run/nginx.pid;

events {
    worker_connections 1024;
    use epoll;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    log_format main '$remote_addr - $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';

    access_log /var/log/nginx/access.log main;
    error_log /var/log/nginx/error.log warn;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 65;
    types_hash_max_size 2048;
    client_max_body_size 100M;

    gzip on;
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_types text/plain text/css text/xml text/javascript
               application/json application/javascript application/xml+rss
               application/rss+xml font/truetype font/opentype
               application/vnd.ms-fontobject image/svg+xml;

    upstream php {
        server 127.0.0.1:9000;
    }

    server {
        listen 8080 default_server;
        server_name _;
        root /var/www/html;
        index index.php index.html;

        location / {
            try_files $uri $uri/ /index.php?$query_string;
        }

        location ~ \.php$ {
            try_files $uri =404;
            fastcgi_split_path_info ^(.+\.php)(/.+)$;
            fastcgi_pass php;
            fastcgi_index index.php;
            include fastcgi_params;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2)$ {
            expires 30d;
            add_header Cache-Control "public, immutable";
        }

        location ~ /\. {
            deny all;
            access_log off;
            log_not_found off;
        }
    }
}

Create Entrypoint Script

Create entrypoint.sh for initialization:

#!/bin/sh

set -e

echo "Starting Cloudlog initialization..."

# Wait for network connectivity
echo "Waiting for network to be ready..."
sleep 5

# Check database connectivity
if [ ! -z "$DB_HOST" ]; then
    echo "Waiting for database..."

    if [ "$DB_TYPE" = "mysql" ]; then
        until mysql -h "$DB_HOST" -P "${DB_PORT:-3306}" -u "$DB_USER" -p"$DB_PASSWORD" -e "SELECT 1" > /dev/null 2>&1; do
            echo "Database is unavailable - sleeping"
            sleep 2
        done
    elif [ "$DB_TYPE" = "pgsql" ]; then
        until PGPASSWORD="$DB_PASSWORD" psql -h "$DB_HOST" -p "${DB_PORT:-5432}" -U "$DB_USER" -d "$DB_NAME" -c "SELECT 1" > /dev/null 2>&1; do
            echo "Database is unavailable - sleeping"
            sleep 2
        done
    fi

    echo "Database is available"
fi

# Run database migrations if needed
if [ -f "/var/www/html/application/migrations/migration_script.php" ]; then
    echo "Running database migrations..."
    php /var/www/html/application/migrations/migration_script.php
fi

# Set proper permissions
chmod -R 755 /var/www/html/application/logs

# Start PHP-FPM and Nginx
echo "Starting PHP-FPM and Nginx..."

php-fpm -D
nginx -g "daemon off;"

Building the Dockerfile Locally (Optional)

Test the Dockerfile locally:

# Build the Docker image
docker build -t cloudlog:latest .

# Run the container locally (for testing only)
docker run -d \
  --name cloudlog-test \
  -p 8080:8080 \
  -e DB_TYPE=mysql \
  -e DB_HOST=db.example.com \
  -e DB_PORT=3306 \
  -e DB_USER=cloudlog_user \
  -e DB_PASSWORD=secure_password \
  -e DB_NAME=cloudlog \
  cloudlog:latest

# Wait for container to start
sleep 10

# Access the application
# http://localhost:8080

Deploying with Docker on Klutch.sh

Klutch.sh automatically detects a Dockerfile in your repository root and uses it for deployment.

Prerequisites for Docker Deployment

Your Cloudlog project pushed to GitHub with Dockerfile
Persistent storage configured for logs and data
Database connection details (MySQL or PostgreSQL)
Network access to your database

Steps to Deploy with Docker

Prepare Your Repository

Commit and push all necessary files:

git add Dockerfile entrypoint.sh nginx.conf .dockerignore
git commit -m "Add Docker deployment configuration for Cloudlog"
git push origin main

Log In to Klutch.sh Dashboard
Go to klutch.sh/app and sign in with your GitHub account.
Create a Project
Navigate to the Projects section and create a new project for your Cloudlog instance.
Create an App
Click “Create App” and select your GitHub repository containing the Cloudlog Docker configuration.
Select the Branch
Choose the branch you want to deploy (typically main).
Configure Traffic Type
Select HTTP as the traffic type for Cloudlog (a web application).
Set the Internal Port
Set the internal port to 8080 – this is the port where Nginx listens.

Add Environment Variables

Configure environment variables for your Cloudlog instance:

# Database Configuration
DB_TYPE=mysql
DB_HOST=db.example.com
DB_PORT=3306
DB_USER=cloudlog_user
DB_PASSWORD=secure_database_password
DB_NAME=cloudlog

# Application Configuration
APP_NAME=Cloudlog
APP_URL=https://example-app.klutch.sh
APP_ENV=production
APP_DEBUG=false

# Admin Configuration
ADMIN_EMAIL=admin@example.com
ADMIN_CALL=YourCall
ADMIN_PASSWORD=change_this_to_secure_password

# Security Configuration
ENCRYPTION_KEY=your_encryption_key_here
SESSION_TIMEOUT=3600
HTTPS=true

# Email Configuration (optional)
MAIL_HOST=smtp.example.com
MAIL_PORT=587
MAIL_USERNAME=your-email@example.com
MAIL_PASSWORD=your-password
MAIL_FROM=noreply@example.com
MAIL_ENCRYPTION=tls

# Features
ENABLE_API=true
ENABLE_CONTESTS=true
ENABLE_AWARDS=true
ENABLE_DXCC=true
ENABLE_CLUBS=false

# Performance Settings
PHP_MEMORY_LIMIT=256M
PHP_MAX_EXECUTION_TIME=300
PHP_MAX_INPUT_VARS=10000
PHP_UPLOAD_MAX_FILESIZE=100M

# Logging
LOG_LEVEL=info
LOG_CHANNEL=single

# Timezone
TZ=UTC

Replace with your actual values. Generate secure passwords for production.

Configure Persistent Storage
Cloudlog needs persistent volumes for logs and configuration data:
1. After creating the app, go to Volumes
2. Add volume for logs:
  - Mount path: /var/www/html/application/logs
  - Size: 1-2 GiB (adjust based on logging volume)
3. Add volume for data (optional but recommended):
  - Mount path: /var/www/html/application/data
  - Size: 2-5 GiB (for backups and exports)
Configure Compute Resources
Select appropriate resources:
- Minimum: 1-2 CPU, 512 MB - 1 GB RAM (small deployments, personal use)
- Recommended: 2-4 CPU, 1-2 GB RAM (small group operations)
- Large: 4-8 CPU, 2-4 GB RAM (large club operations, 20+ concurrent users)
Select region closest to your location or primary user base.
Deploy
Click “Create” to start deployment. Klutch.sh will:
1. Build the Docker image (building Cloudlog takes 5-10 minutes)
2. Start the Cloudlog container
3. Assign a public URL (e.g., example-app.klutch.sh)
4. Configure HTTPS automatically
Complete Initial Setup
After deployment, access your Cloudlog instance:
1. Navigate to https://example-app.klutch.sh
2. Log in with the administrator credentials (from environment variables)
3. Configure station profile:
  - Enter your callsign
  - Set location and coordinates
  - Configure band/mode preferences
  - Upload station photo (if desired)
4. Set up awards tracking:
  - Enable DXCC tracking
  - Configure award goals
  - Enable badge system
5. Configure contest logging:
  - Add contest rules
  - Set contest parameters
  - Configure scoring
6. Configure user accounts:
  - Create user accounts for operators
  - Assign permissions
  - Set up station access
7. Test logging:
  - Log sample QSOs
  - Test contest logging
  - Verify award tracking
8. Configure email (if applicable):
  - SMTP settings
  - Email notifications
Test Functionality
Verify all features are working:
1. Create test QSO logs
2. Test contest logging
3. Verify DXCC tracking
4. Test user account creation
5. Verify role-based access control
6. Test report generation
7. Test data export
8. Check application logs for errors

Cloudlog Features and Configuration

1. QSO Logging

Log and manage radio contacts:

Logging Features:

Callsign input with lookup
Frequency and mode selection
Time and duration tracking
Signal reports (RST)
Notes and comments
Quick logging interface
Batch import from files

Log QSOs:

Go to Log QSO section
Enter callsign (auto-lookup available)
Select frequency and mode
Enter signal reports
Add notes if needed
Save QSO
Continue with next contact
Review logged contacts

2. Contest Logging

Manage contest operations:

Contest Features:

Contest framework selection
Exchange tracking
Scoring calculations
Category management
Score validation
Contest-specific rules
Multiplier tracking

Configure contests:

Go to Contests section
Select contest type
Set contest parameters
Configure exchange format
Start logging QSOs
Monitor score progress
Generate contest reports
Submit contest entry

3. Award Tracking

Track operating achievements:

Award Features:

DXCC country tracking
Award progress monitoring
Badge system
Certificate generation
Goal setting
Statistics and reports
Award verification

Configure awards:

Go to Awards section
Enable tracking for desired awards
Set personal goals
Monitor progress
View statistics
Generate certificates
Track achievements
Share accomplishments

4. Digital Mode Support

Manage digital communications:

Digital Features:

FT8, PSK, RTTY logging
Mode-specific parameters
Signal report formats
Frequency tracking
Mode statistics
Digital alert notifications
Integration with digital tools

Log digital modes:

Go to Log QSO section
Select digital mode
Enter mode-specific details
Log the contact
View digital statistics
Monitor band activity
Generate mode reports

5. User Management

Manage operator access:

User Features:

Multi-user support
Role-based permissions
Station profiles
User preferences
Activity tracking
Permission management
User deactivation

Manage users:

Go to Admin > Users
Create operator accounts
Assign callsigns
Set permissions
Configure station access
Enable/disable users
Monitor user activity
Manage user preferences

6. API Integration

Enable external integrations:

API Features:

REST API for third-party tools
Webhook support
Mobile app integration
LoTW integration (optional)
External log uploaders
Data export APIs
Real-time QSO updates

Configure API:

Go to Admin > API
Enable API access
Generate API tokens
Configure webhook endpoints
Test API connectivity
Monitor API usage
Manage integrations

7. Reporting and Statistics

Generate insights and reports:

Report Features:

QSO summaries
Band and mode statistics
Country/region reports
Time-based analysis
Award progress reports
Custom report builder
Data export options

Generate reports:

Go to Reports section
Select report type
Configure report parameters
Generate report
View results
Export to CSV or PDF
Schedule recurring reports
Share reports

8. Import and Export

Transfer data in and out:

Import/Export Features:

ADIF import support
CSV import/export
Data backup
Contest result export
Award certificate generation
Statistics export
Data migration tools

Import/export data:

Go to Tools > Import/Export
Select import or export
Choose file format
Configure options
Execute operation
Verify results
Download files
Archive backups

Persistent Storage

Cloudlog requires persistent storage for logs, configurations, and data exports:

Critical Data Directories

/var/www/html/
├── application/logs/          (application logs)
├── application/data/          (QSO data)
├── application/config/        (user configurations)
└── uploads/                   (backup files)

Adding Persistent Volumes

In Klutch.sh dashboard, go to your Cloudlog app
Navigate to Volumes section
Add volume for application logs:
- Mount path: /var/www/html/application/logs
- Size: 1-2 GiB
Add volume for data files:
- Mount path: /var/www/html/application/data
- Size: 2-5 GiB

Backup Strategy

Implement regular backup routine:

#!/bin/bash
# Daily backup script

BACKUP_DIR="/backups/cloudlog"
DATE=$(date +%Y%m%d_%H%M%S)
RETENTION_DAYS=30

# Create backup directory
mkdir -p $BACKUP_DIR

# Backup application data
tar -czf $BACKUP_DIR/cloudlog_data_$DATE.tar.gz /var/www/html/application/data/

# Backup configuration
tar -czf $BACKUP_DIR/cloudlog_config_$DATE.tar.gz /var/www/html/application/config/

# Database backup (MySQL)
mysqldump -h $DB_HOST -u $DB_USER -p$DB_PASSWORD $DB_NAME | gzip > $BACKUP_DIR/cloudlog_db_$DATE.sql.gz

# Delete old backups
find $BACKUP_DIR -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete
find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete

# Upload to remote storage
# aws s3 sync $BACKUP_DIR s3://my-backup-bucket/cloudlog/

Security Best Practices

1. HTTPS/SSL Enforcement

Klutch.sh automatically provides HTTPS for your web interface. All traffic is encrypted by default.

2. Authentication and Authorization

Implement strong access control:

Authentication Methods:

Username/password with strong requirements
API token authentication
Session management
Multi-user access control
Role-based permissions

Configure authentication:

Go to Admin > Security
Set password policy (minimum 12 characters)
Configure session timeout (30 minutes recommended)
Enable login logging
Set API token expiration
Regular access audits

3. Database Security

Protect your database:

Configuration:
- Use strong database passwords
- Encrypt database connections
- Limit database user permissions
- Use parameterized queries
- Regular database backups
- Monitor database access

4. Network Security

Secure network access:

HTTPS enforced for all connections
Firewall rules for database access
Restrict API access by IP (if applicable)
Use VPN for remote database connections
Monitor network traffic
Enable DDoS protection (Klutch.sh provides)

5. Access Control

Implement granular access control:

User-level permissions
Role-based access control
Station-level isolation
API token management
Permission auditing
Regular permission reviews

6. Data Protection

Protect data in transit and at rest:

HTTPS for web traffic
SSL/TLS for database connections
Encryption of sensitive data
Secure password storage (hashing)
Data retention policies
Secure data deletion

7. API Security

Secure API access:

- Require API token authentication
- Generate secure tokens
- Set API rate limits
- Log all API access
- Restrict API permissions
- Rotate tokens regularly

Performance Optimization

1. PHP Configuration

Optimize PHP settings:

PHP_MEMORY_LIMIT=256M
PHP_MAX_EXECUTION_TIME=300
PHP_MAX_INPUT_VARS=10000
PHP_UPLOAD_MAX_FILESIZE=100M
PHP_POST_MAX_SIZE=100M

2. Database Optimization

Optimize database performance:

Configuration:
- Use database indexes on common searches
- Archive old QSO records quarterly
- Optimize log tables
- Monitor query performance
- Configure connection pooling
- Set appropriate cache settings

3. Caching Strategy

Implement caching:

Caching Options:
- Cache country lists and data
- Cache user preferences
- Cache report results
- Cache API responses
- Implement query caching

4. Resource Monitoring

Monitor system resources:

# Check PHP-FPM status
curl http://localhost:8080/fpm-status

# Monitor disk usage
df -h /var/www/html

# View application logs
tail -f /var/www/html/application/logs/app.log

5. Large Data Sets

Handle large log datasets:

Strategies:
- Archive old QSO records
- Use pagination for QSO lists
- Optimize report queries
- Batch import operations
- Monitor memory usage
- Use compression for exports

Monitoring and Logging

1. Access Application Logs

View Cloudlog logs through Klutch.sh:

Go to your app in Klutch.sh
Click Logs
Filter by time range and log level
Search for specific errors or events

2. Configure Logging

Configure logging levels:

LOG_LEVEL options:
- debug: Detailed debug information
- info: Informational messages (default)
- warning: Warning messages
- error: Error messages only
- critical: Critical errors only

3. Monitor Real-Time Metrics

Track real-time performance:

Metrics to monitor:
- Active user sessions
- QSO logging rate
- API response times
- Database query performance
- Memory usage
- Disk space usage
- CPU utilization
- Request per second

4. Health Checks

Cloudlog includes health endpoints:

# Health check endpoint
curl -f http://localhost:8080/health

# Status information
curl http://localhost:8080/api/status

5. Monitoring Integration

Integrate with monitoring services:

Prometheus: Metrics collection
Grafana: Visualization dashboards
DataDog: Infrastructure monitoring
New Relic: Performance monitoring
ELK Stack: Centralized logging

Custom Domains

To use a custom domain with your Cloudlog instance:

1. Add Domain in Klutch.sh

In the Klutch.sh dashboard, go to your app settings and add your custom domain (e.g., log.example.com).

2. Update DNS Configuration

Update your DNS provider:

CNAME: log.example.com → example-app.klutch.sh

3. Update Environment Variables

Update Cloudlog configuration:

APP_URL=https://log.example.com

Redeploy the application to apply changes.

4. Verify DNS Propagation

Check DNS resolution:

nslookup log.example.com
# or
dig log.example.com CNAME

Once propagated, your Cloudlog instance will be accessible at your custom domain with automatic HTTPS.

Troubleshooting

Issue 1: Container Won’t Start

Error: Container exits immediately or doesn’t respond

Solutions:

Check Docker logs: docker logs container_id
Verify Dockerfile builds locally: docker build -t cloudlog:test .
Ensure environment variables are set correctly
Check database connectivity settings
Verify entrypoint script has execute permissions
Wait for container to initialize (30+ seconds)

Issue 2: Cannot Access Web Interface

Error: 503 Service Unavailable or connection timeout

Solutions:

Verify Cloudlog is running: Check container status
Verify port 8080 is exposed and traffic is HTTP
Check firewall rules: Ensure port 8080 is accessible
Verify DNS resolution: dig example-app.klutch.sh
Check Cloudlog logs for startup errors
Verify PHP-FPM and Nginx are running
Check disk space availability

Issue 3: Database Connection Failures

Error: Cannot connect to database from Cloudlog

Solutions:

Verify database credentials are correct
Check database host and port are correct
Verify database user has proper permissions
Test connection with database client locally first
Enable debug logging to see connection details
Check database firewall allows connections
Verify database is running and accessible
Test with simpler configuration first

Issue 4: QSO Logging Slow or Unresponsive

Error: Slow response times when logging QSOs or viewing logs

Solutions:

Check available memory: Monitor container memory usage
Archive old QSO records (e.g., logs older than 1 year)
Optimize database indexes
Increase PHP memory limit
Monitor database query performance
Increase container resources in Klutch.sh
Check disk I/O performance
Reduce number of concurrent users

Issue 5: File Upload Issues

Error: Cannot upload files or export data

Solutions:

Verify persistent volumes are mounted correctly
Check disk space in persistent volumes
Verify upload directory permissions
Check file size limits in PHP configuration
Review file upload logs
Increase PHP upload limits if needed
Verify file format is supported

Issue 6: User Account Issues

Error: Cannot log in or create users

Solutions:

Verify database password is correct
Check user account exists and is enabled
Reset password if necessary
Clear session cookies in browser
Verify session timeout settings
Review audit logs for login attempts
Check user permissions are set correctly

Issue 7: Memory Usage Too High

Error: Container using excessive memory, OOM errors

Solutions:

Check current memory allocation: docker stats
Increase container memory allocation
Archive old QSO records
Reduce PHP memory limit if too high
Monitor garbage collection
Optimize database queries
Review PHP configuration

Issue 8: Report Generation Fails

Error: Reports fail to generate or timeout

Solutions:

Increase PHP execution time limit
Reduce report date range
Archive older QSO data
Check database performance
Verify disk space for temporary files
Review report generation logs
Increase container resources

Best Practices

1. QSO Management

Manage QSO data effectively:

Log QSOs promptly after contact
Use standard abbreviations and formats
Verify callsigns using databases
Include accurate time information
Use appropriate signal reports
Add relevant notes for each contact
Regular data backup
Archive old logs periodically

2. Contest Logging

Manage contest operations:

Verify contest rules before logging
Use correct exchange format
Monitor score progression
Validate exchange information
Test setup before contest
Keep detailed notes
Backup contest logs
Archive completed contests

3. User Management

Manage user access effectively:

Implement strong password policies
Regular user access reviews
Disable unused accounts
Assign appropriate permissions
Limit sensitive operations
Monitor user activity
Regular training on features
Document user roles

4. Data Management

Maintain data integrity:

Regular backup schedule
Test restore procedures
Archive historical data
Verify data exports
Document backup procedures
Monitor data growth
Clean up temporary files
Implement retention policies

5. Performance Tuning

Keep system performing well:

Monitor memory usage
Optimize database queries
Archive old records
Monitor disk usage
Review access logs
Tune PHP settings
Monitor query performance
Plan for growth

6. Security Maintenance

Keep system secure:

Regular password reviews
Monitor failed logins
Review audit logs
Update software regularly
Test security measures
Document security policies
Incident response planning
Regular security training

7. Maintenance Schedule

Plan regular maintenance:

Weekly: Review system logs
Monthly: Archive old records, backup verification
Quarterly: Database optimization, user review
Semi-annually: Security audit, performance review
Annually: Full system assessment, disaster recovery test

8. Documentation

Maintain comprehensive documentation:

User guides for operators
Administration procedures
System configuration details
Backup and recovery procedures
Troubleshooting guides
API documentation
Security policies
Emergency procedures

9. Community Engagement

Engage with radio community:

Participate in contests
Share logs with clubs
Contribute to DXCC tracking
Join online communities
Share best practices
Provide feedback to developers
Help other operators
Document lessons learned

10. Continuous Improvement

Keep improving your setup:

Monitor system performance
Gather user feedback
Test new features
Document improvements
Share improvements with community
Optimize workflows
Enhance security
Plan for future growth

Verifying Your Deployment

After deployment completes:

Check the App URL: Visit https://example-app.klutch.sh
Log In: Use administrator credentials from environment variables
Configure Station: Enter your callsign and station details
Log Test QSO: Create a test contact entry
Test Contest Logging: Enable and test contest logging
Test Awards: Verify DXCC tracking is working
Create Test User: Add a user account and verify permissions
Test Export: Export QSOs to CSV
Check Persistence: Verify data persists after restart
Review Logs: Check application logs for errors

If your Cloudlog instance doesn’t work as expected, review the troubleshooting section and check the Klutch.sh dashboard logs for detailed error messages.

External Resources

Deploying Cloudlog to Klutch.sh using Docker provides a powerful, open-source web-based amateur radio logging platform with complete control over your logging infrastructure. By following this guide, you’ve learned how to create a production-ready Dockerfile with PHP and Nginx, configure persistent storage for logs and data, set up user management and role-based access control, configure database connectivity for QSO storage, enable contest logging and award tracking, implement security best practices, optimize PHP and database performance, configure custom domains, monitor system health and performance, and troubleshoot common issues. Your Cloudlog instance is now running on Klutch.sh’s global infrastructure with professional-grade hosting, automatic HTTPS, scalable resources, and reliable infrastructure for amateur radio operations. For additional help or questions, consult the official Cloudlog documentation or contact Klutch.sh support.