Deploying Baserow on

Configuration

After successfully launching Baserow with Docker Compose, final configuration is required to ensure secure and convenient access. This includes setting up a domain name, HTTPS, and additional parameters.

1. DNS Configuration

To access Baserow via a domain name (e.g., baserow.yourdomain.com), you need to create an A-record with your domain name registrar. Specify your domain (or subdomain) and the IP address of your VPS.

# Example record with your domain registrar
Type: A
Host: baserow
Value: YOUR_VPS_IP_ADDRESS

Wait for DNS records to update (this may take from a few minutes to several hours).

2. Caddy Configuration for HTTPS

Baserow Docker Compose by default includes the Caddy service, which acts as a reverse proxy and automatically manages Let's Encrypt certificates for HTTPS. Configuration is done via the Caddyfile.

By default, the Caddyfile is already configured in the baserow/caddy directory. Ensure that in your docker-compose.yml, the Caddyfile is mounted into the Caddy container:

# Contents of docker-compose.yml (Caddy fragment)
# ...
  caddy:
    image: caddy:2.7.6-alpine # Current Caddy version for 2026
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - baserow_caddy_data:/data
      - baserow_caddy_config:/config
    depends_on:
      - baserow_web
# ...

Create the caddy directory and a Caddyfile inside it, if they don't exist:

mkdir caddy
nano caddy/Caddyfile

Add or ensure that the caddy/Caddyfile contains the following (replace baserow.yourdomain.com with your domain):

{
  # Replace with your email for Let's Encrypt notifications
  email [email protected]
}

baserow.yourdomain.com {
  reverse_proxy baserow_web:80
}

After editing the Caddyfile, if you made changes, you only need to restart the Caddy service:

docker compose restart caddy # Restart the Caddy container

Caddy will automatically detect the new domain, request a Let's Encrypt certificate, and configure HTTPS. If you encounter issues, check Caddy's logs:

docker compose logs caddy # View Caddy logs

3. Verifying Functionality

After configuring DNS and Caddy, check Baserow's availability:

• Website Availability: Open your domain (https://baserow.yourdomain.com) in a browser. You should see the Baserow registration/login page.
• HTTPS Check: Ensure that the connection is secure (green padlock in the address bar).
• Domain Ping: Verify that the domain resolves to the correct IP address.

ping baserow.yourdomain.com

• Container Healthcheck: Ensure that all Docker containers are running without errors.

docker compose ps
docker compose logs

If Baserow loads, you can register the first user (administrator) and start working with the platform.

4. Additional Settings in .env (if needed)

The .env file contains many other settings that may be useful later:

• BASEROW_EMAIL_SMTP_HOST, BASEROW_EMAIL_SMTP_PORT, etc.: SMTP server settings for sending emails (notifications, password reset).
• BASEROW_PUBLIC_BACKEND_URL: If you are using a separate backend different from the main domain.
• MEDIA_ROOT: Path for storing user files. By default, this is a Docker volume.

Always refer to the official Baserow documentation for a complete list and description of all environment variables.

Important: Never store sensitive data (passwords, API keys) directly in code or publicly accessible files. The .env file must be protected and should not be committed to version control systems.

Backups and Maintenance

Regular backups and timely maintenance are critically important for any production system. This ensures the safety of your data and the stability of Baserow's operation.

1. What to Back Up

For Baserow, the following components need to be backed up:

• PostgreSQL Database: Contains all structured data created in Baserow. This is the most important component.
• User Files (Media): All files uploaded by users to Baserow (images, documents, etc.). They are stored in the Docker volume associated with the service baserow_backend.
• Configuration Files: docker-compose.yml and .env. They contain deployment settings and secret keys necessary for system recovery.

2. Simple Auto-Backup Script

Let's create a simple script for automatic backup. This script will dump the database, archive media files, and save configuration files. It is assumed that you are in the ~/baserow directory.

mkdir -p ~/baserow_backups # Create directory for backups
nano ~/baserow_backups/backup_baserow.sh

Add the following content to the file backup_baserow.sh. Replace YOUR_DB_USER and YOUR_DB_PASSWORD with values from your .env file:

#!/bin/bash

# Settings
BACKUP_DIR="/home/baserow_admin/baserow_backups" # Directory for storing backups
BASEROW_DIR="/home/baserow_admin/baserow"       # Directory where docker-compose.yml is located
TIMESTAMP=$(date +%Y%m%d_%H%M%S)

# Variables from .env (needed for pg_dump)
# Can be read from .env or set manually
# Example of reading from .env (requires jq, which can be installed: sudo apt install jq -y)
# source "$BASEROW_DIR/.env" # If .env is simple, without special characters

# Or set manually if .env has complex characters or you don't want to parse it
DB_NAME="baserow"
DB_USER="baserow"
DB_PASSWORD="YOUR_STRONG_DATABASE_PASSWORD_HERE" # Replace with the actual password from .env

# 1. PostgreSQL Database Backup
echo "Dumping PostgreSQL database..."
docker compose -f "$BASEROW_DIR/docker-compose.yml" exec -T database pg_dump -U "$DB_USER" -d "$DB_NAME" > "$BACKUP_DIR/baserow_db_${TIMESTAMP}.sql"
if [ $? -eq 0 ]; then
    echo "Database dump successful: $BACKUP_DIR/baserow_db_${TIMESTAMP}.sql"
else
    echo "Database dump FAILED!"
    exit 1
fi

# 2. Media Files Backup (Docker volume)
echo "Archiving Baserow media files..."
# Get the name of the volume for media files
MEDIA_VOLUME=$(docker volume ls -q | grep baserow_data) # Assumes the volume name contains 'baserow_data'
if [ -z "$MEDIA_VOLUME" ]; then
    echo "Could not find Baserow media volume. Skipping media backup."
else
    # Create a temporary container to copy data
    docker run --rm -v "$MEDIA_VOLUME":/data -v "$BACKUP_DIR":/backup_dest alpine tar -czvf "/backup_dest/baserow_media_${TIMESTAMP}.tar.gz" -C /data .
    if [ $? -eq 0 ]; then
        echo "Media files archive successful: $BACKUP_DIR/baserow_media_${TIMESTAMP}.tar.gz"
    else
        echo "Media files archive FAILED!"
    fi
fi

# 3. Copying Configuration Files
echo "Copying configuration files..."
cp "$BASEROW_DIR/docker-compose.yml" "$BACKUP_DIR/docker-compose_${TIMESTAMP}.yml"
cp "$BASEROW_DIR/.env" "$BACKUP_DIR/.env_${TIMESTAMP}"
echo "Configuration files copied."

# Deleting old backups (e.g., older than 7 days)
echo "Removing old backups..."
find "$BACKUP_DIR" -type f -name "baserow_db_*.sql" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "baserow_media_*.tar.gz" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name "docker-compose_*.yml" -mtime +7 -delete
find "$BACKUP_DIR" -type f -name ".env_*" -mtime +7 -delete
echo "Old backups removed."

echo "Baserow backup completed at $TIMESTAMP"

Make the script executable:

chmod +x ~/baserow_backups/backup_baserow.sh # Make the script executable

3. Scheduling Backups with Cron

Add the script to Cron for daily execution (e.g., at 3:00 AM):

crontab -e # Open crontab for editing

Add the following line to the end of the file (choose nano editor if prompted):

0 3 * * * /home/baserow_admin/baserow_backups/backup_baserow.sh >> /var/log/baserow_backup.log 2>&1

This line means: at 3:00 AM every day, run the script and redirect all output to the log file /var/log/baserow_backup.log.

4. Where to Store Backups

Storing backups on the same server as production data is extremely risky. If the server fails, you will lose both your data and your backups. It is recommended to use:

• External S3-compatible storage: Services such as AWS S3, Backblaze B2, DigitalOcean Spaces. Utilities like rclone or s3cmd can be used for automatic synchronization of local backups with S3.
• Separate VPS: An inexpensive VPS in another location, where backups can be copied via SSH using rsync.
• Network Attached Storage (NAS): If you have your own infrastructure.

Extend the backup script by adding a step to copy files to remote storage.

5. Updates: Rolling vs. Maintenance Window

Regular updates of Baserow and underlying software are important for security and new features.

• Updating Baserow:

  To update Baserow to a new version (e.g., from 1.24.x to 1.25.x), follow these steps:

  1. Perform a full backup! This is the most important step before any update.
  2. Stop Baserow:

     
     cd ~/baserow
     docker compose down
                         

  3. Download new versions of docker-compose.yml and .env files (or compare and update current ones):

     
     wget -O docker-compose.yml https://gitlab.com/baserow/baserow/-/raw/develop/deploy/docker-compose.yml
     # Check .env for new variables, if they appeared in the new Baserow version
                         

  4. Start Baserow with updated images:

     
     docker compose pull # Download new images
     docker compose up -d # Start with new images and DB migration, if needed
                         

  5. Check logs and functionality.

  This will require a short maintenance window (service downtime), as the database may require migration. Always read the official Baserow update documentation for the specific version.

• OS and Docker Updates:

  Regularly update the operating system and Docker Engine:

  
  sudo apt update && sudo apt upgrade -y
  sudo systemctl reboot # Reboot to apply kernel updates
              

  Docker updates may also require restarting containers or even the entire server. Plan these operations during periods of low activity.

Troubleshooting + FAQ

Even with the most careful approach, problems can arise. Here we will cover typical scenarios and questions.

Baserow container is not starting or keeps restarting. What to do?

What to check: First, look at the logs of the problematic container. For example, for the backend: docker compose logs baserow_backend. Pay attention to error messages. Common causes include: insufficient memory, incorrect environment variables in .env (especially DATABASE_URL, SECRET_KEY, BASEROW_PUBLIC_URL), port conflicts, corrupted Docker images or volumes.

How to fix: Ensure your VPS has enough RAM. Check the syntax and values in .env. If there's suspicion of corrupted volumes, try stopping Baserow (docker compose down) and, as a last resort, removing volumes (docker volume rm baserow_data baserow_caddy_data baserow_caddy_config), then restarting (losing data if not backed up!). Sometimes a complete recreation of images helps: docker compose build --no-cache && docker compose up -d.

Cannot access Baserow by domain name, or HTTPS is not working.

What to check: Ensure that the DNS record for your domain (e.g., baserow.yourdomain.com) points to the correct IP address of your VPS. Use ping your.domain or dig your.domain. Check that ports 80 and 443 are open on your VPS (sudo ufw status). Look at Caddy logs: docker compose logs caddy for errors when obtaining a Let's Encrypt certificate. Make sure that BASEROW_PUBLIC_URL in .env and the domain in caddy/Caddyfile match.

How to fix: Correct the DNS record. Open ports 80 and 443 in UFW. If Caddy cannot obtain a certificate, there might be a DNS resolution issue, or the domain does not point to your server. Ensure that the email in Caddyfile is correct.

Baserow is running very slowly.

What to check: Use htop or top on the VPS to check CPU load and RAM usage. Slowness is often related to insufficient resources. Also, check Baserow logs for recurring errors that might slow down performance.

How to fix: If RAM is insufficient, consider increasing the VPS memory. If the CPU is constantly loaded, more cores might be needed. Optimize queries in Baserow, avoid very large tables with many relationships and complex formulas if performance is critical. Ensure that the disk subsystem uses SSD.

What is the minimum VPS configuration suitable for Baserow?

Answer: For testing or a very small team (1-2 users), the minimum configuration is 2 CPU cores, 2 GB RAM, and 40 GB SSD. However, for stable and comfortable operation with a small team (up to 10-15 people), at least 2-4 CPU cores, 4 GB RAM, and 80 GB SSD are recommended. An SSD is mandatory for good database performance.

What to choose – VPS or dedicated for this task?

Answer: For most Baserow use cases (personal projects, small to medium teams), a VPS is the optimal choice. It offers sufficient performance, flexibility, and cost-effectiveness. A dedicated server is only needed for very high loads (hundreds of active users, terabytes of data), specific hardware requirements, or strict regulatory norms requiring full control over physical equipment. Start with a VPS and scale to a dedicated server if a real need arises.

How to reset the Baserow admin password if I forgot it?

What to check: If you have configured SMTP, you can use the "Forgot password" function on the login page. If SMTP is not configured, you will need to reset the password via the Docker console.

How to fix: Connect to the server via SSH, navigate to the Baserow directory (~/baserow). Then execute the command to reset the password for the user with the specified email:

docker compose exec baserow_backend python3 manage.py reset_user_password --email [email protected]

This command will generate a temporary password that you can use to log in, and then change it within the Baserow interface.

VPS disk space is full.

What to check: Use df -h to check overall disk usage and du -sh /var/lib/docker/volumes/* to check Docker volume sizes. Often, old Docker images, cache, or logs occupy space.

How to fix: Clean up old Docker objects: docker system prune -a (caution: this removes all stopped containers, unused networks, images, and volumes). Regularly delete old backups, especially local ones. Consider increasing VPS disk space or moving backups to external storage.

Conclusion and Next Steps

Congratulations! You have successfully deployed Baserow on your VPS, configured secure access via HTTPS, and implemented a basic backup strategy. Now you have a powerful, flexible, and fully controlled no-code database, ready for use by your team or for your personal projects. You have gained full control over your infrastructure and data, which is a key advantage of self-hosted solutions.

Here are a few steps you can take next:

• Monitoring: Set up a monitoring system (e.g., Prometheus + Grafana) to track the status of your VPS and Baserow's performance. This will help identify issues proactively.
• Scaling: As the number of users or data volume grows, consider increasing your VPS resources (CPU, RAM, disk). For very large loads, Baserow supports horizontal scaling, allowing you to run multiple backend and frontend instances.
• Integrations: Utilize Baserow's powerful API to integrate with your other applications, scripts, or external services, automating workflows and extending functionality.
• Additional Security: Consider setting up a VPN for admin panel access, more complex firewall rules, or using an intrusion detection system.