Deploying Budibase on a VPS: a low-code platform for internal applications
TL;DR
In this detailed guide, we will step-by-step set up and launch Budibase, a powerful low-code platform for creating internal applications, on your own Virtual Private Server (VPS). You will learn how to prepare the server, install Docker and Docker Compose, deploy Budibase, configure HTTPS using Caddy, and ensure regular backups and maintenance for stable operation of your applications.
- Setting up Budibase on a VPS provides full control over data and infrastructure.
- We use Docker and Docker Compose for easy Budibase deployment and management.
- We ensure security with automatic HTTPS via Caddy and basic server protection.
- We consider optimal VPS configurations for various Budibase use cases.
- We provide scripts and recommendations for system backup and updates, guaranteeing fault tolerance.
- The guide covers the entire deployment lifecycle from server selection to maintenance.
What we are setting up and why
In this guide, we will focus on deploying Budibase – a modern open-source low-code platform designed for quickly building internal tools, portals, and applications. Budibase allows developers and even non-technical specialists to create powerful web applications by connecting to various data sources (PostgreSQL, MySQL, MongoDB, Airtable, REST API) and using an intuitive interface builder.
Ultimately, you will get a fully functional Budibase instance, accessible via your domain name with a secure HTTPS connection. This will enable you and your team to rapidly develop and implement internal applications, automate business processes, and manage data, without resorting to expensive third-party SaaS solutions or lengthy manual development.
Why Budibase on a VPS, not cloud alternatives?
There are many solutions on the market for creating internal applications. They can be broadly divided into two categories:
-
Cloud-managed (SaaS) platforms: Such as Retool, Appsmith Cloud, Internal.io. They offer a fully managed environment where you don't have to worry about infrastructure. You simply sign up and start building.
Pros: No need for server management, quick readiness for work, scalability from the provider.
Cons: High cost with increasing number of users or application complexity, dependence on the provider, limited customization and integration options at the infrastructure level, potential data privacy issues if stored on third-party servers.
-
Self-hosted platforms: Budibase, Appsmith Community Edition, NocoDB, ToolJet. You install these solutions on your own server.
Pros: Full control over data and infrastructure, usually lower total cost of ownership in the long run, high flexibility in configuration and integration with your existing infrastructure, possibility of source code customization (for open-source solutions), independence from third-party service pricing policies.
Cons: Requires technical expertise for installation and maintenance, responsibility for security and scaling falls on you.
Choosing Budibase on a VPS is ideal if you value control, data privacy, and budget savings, and are willing to invest time in initial setup and maintenance. This is especially relevant for solo SaaS founders, developers who need to quickly set up internal tools, and companies for whom data localization and regulatory compliance are important.
What VPS configuration is needed for this task
Budibase, being a Docker-based platform, can be quite resource-intensive, especially if you plan to run many applications or serve a large number of users. However, for most internal application scenarios, the requirements are quite moderate.
Minimum requirements (for test environments or 1-5 users):
- CPU: 2 cores (x86-64 architecture)
- RAM: 4 GB (minimum 2 GB for Docker, 2 GB for Budibase and its components)
- Disk: 50 GB SSD (for OS, Docker images, and Budibase data)
- Network: 100 Mbit/s
Recommended requirements (for production environment, 5-20 users, up to 10 applications):
- CPU: 4 cores
- RAM: 8 GB
- Disk: 100-200 GB SSD (with room for data growth and backups)
- Network: 1 Gbit/s
Specific VPS plan for the task
For comfortable work with Budibase, especially if you plan to actively use the platform for multiple teams or more complex applications, it is recommended to choose a VPS with characteristics no lower than the recommended ones. For example, a VPS with 4 CPU cores, 8 GB RAM, 150 GB SSD, and 1 Gbit/s network connection would be suitable. Such configurations provide sufficient performance for most scenarios, and an SSD ensures fast database operations, which is critical for application responsiveness.
When a dedicated server is needed, not a VPS
A dedicated server should be considered if:
- High load: More than 50-100 active users or hundreds of applications are planned.
- Large data volumes: Your applications will work with terabytes of data requiring high I/O performance.
- Strict performance requirements: Guaranteed performance without "noisy neighbors" is needed, which sometimes occurs on a VPS.
- Specific hardware: RAID arrays, GPUs, or other specialized hardware are required.
In such cases, a suitable dedicated server will provide maximum stability and scalability.
Location: what it affects
The choice of VPS location has several key implications:
- Latency: The closer the server is to your users, the lower the latency and faster the application response. If your team is in Europe, choose a European data center.
- Legislation: Some industries or countries have strict data storage requirements (e.g., GDPR in the EU). Placing the server in the appropriate jurisdiction helps comply with these regulations.
- Prices: VPS prices may vary slightly depending on the data center location.
It is recommended to choose a location as close as possible to the primary location of your users to ensure the best user experience.
Server preparation
Before proceeding with Budibase installation, it is necessary to perform basic operating system configuration. We will use Ubuntu Server 24.04 LTS, as it is the current and stable version for 2026.
1. SSH connection
Connect to your VPS as the root user using an SSH client.
ssh root@YOUR_VPS_IP_ADDRESS
If you are using SSH keys, specify the path to your private key:
ssh -i ~/.ssh/id_rsa root@YOUR_VPS_IP_ADDRESS
2. System update
First, update all packages to the latest versions:
sudo apt update && sudo apt upgrade -y
This command updates the package lists and installs all available updates.
3. Creating a new user with sudo privileges
Working as root is insecure. Create a new user and add them to the sudo group.
adduser budiuser # Create a new user "budiuser"
usermod -aG sudo budiuser # Add the user to the sudo group
Set a strong password for the new user. After that, exit the root session and log in as budiuser.
exit # Exit root session
ssh budiuser@YOUR_VPS_IP_ADDRESS # Log in as the new user
4. Configuring SSH keys for the new user (recommended)
For increased security, it is recommended to use SSH keys instead of passwords. Copy your public SSH key to the server:
mkdir -p ~/.ssh # Create directory for keys
chmod 700 ~/.ssh # Set correct permissions
nano ~/.ssh/authorized_keys # Open file to add key
Paste the content of your public key (usually ~/.ssh/id_rsa.pub) into this file and save (Ctrl+X, Y, Enter). Then set the correct permissions:
chmod 600 ~/.ssh/authorized_keys # Set correct permissions for the key file
To disable password authentication and only allow key-based login, edit the /etc/ssh/sshd_config file:
sudo nano /etc/ssh/sshd_config
Find and change the following lines:
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM no # Optional, if not using PAM
After saving, restart the SSH service:
sudo systemctl restart sshd
5. Firewall configuration (UFW)
Enable UFW (Uncomplicated Firewall) and allow only necessary ports (SSH, HTTP, HTTPS).
sudo ufw allow OpenSSH # Allow SSH
sudo ufw allow http # Allow HTTP (port 80)
sudo ufw allow https # Allow HTTPS (port 443)
sudo ufw enable # Enable firewall
sudo ufw status # Check firewall status
Confirm firewall activation by pressing y.
6. Installing Fail2Ban
Fail2Ban helps protect against brute-force attacks by blocking IP addresses that make too many failed login attempts.
sudo apt install fail2ban -y # Install Fail2Ban
sudo systemctl enable fail2ban # Enable autostart
sudo systemctl start fail2ban # Start the service
Create a copy of the configuration file for your setup:
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local # Create local config
sudo nano /etc/fail2ban/jail.local # Edit local config
Ensure that the [sshd] section is active (enabled = true). You can configure bantime (block time) and findtime (period for counting attempts).
[sshd]
enabled = true
port = ssh
logpath = %(sshd_log)s
maxretry = 3 # Maximum number of failed attempts
bantime = 1h # Block time (1 hour)
Save changes and restart Fail2Ban:
sudo systemctl restart fail2ban # Restart Fail2Ban
sudo fail2ban-client status sshd # Check jails status
Software installation — step-by-step
Software Installation — Step-by-Step
Budibase is deployed using Docker and Docker Compose, which significantly simplifies installation and dependency management. We will install the current versions of Docker Engine and Docker Compose, and then deploy Budibase.
1. Docker Engine Installation
First, let's install the necessary packages for Docker:
sudo apt install ca-certificates curl gnupg lsb-release -y # Install necessary packages
Add the official Docker GPG key:
sudo mkdir -p /etc/apt/keyrings # Create directory for keys
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # Add Docker GPG key
sudo chmod a+r /etc/apt/keyrings/docker.gpg # Set access permissions
Add the Docker repository to APT sources:
echo \
"deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
"$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # Add Docker repository
Update the package list and install Docker Engine (current version for 2026, e.g., 25.0.0+):
sudo apt update # Update package lists
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y # Install Docker Engine and plugins
Verify that Docker is installed and running:
sudo systemctl status docker # Check Docker service status
docker --version # Check Docker version
Add our user budiuser to the docker group to avoid using sudo with every Docker command:
sudo usermod -aG docker budiuser # Add user to docker group
newgrp docker # Apply group changes immediately (or re-login)
2. Docker Compose Installation
The Docker Compose plugin is already installed with Docker Engine, but we can check its version:
docker compose version # Check Docker Compose version
For 2026, Docker Compose version 2.20.0 or higher is expected.
3. Git Installation
Git will be needed to clone the Budibase Docker repository.
sudo apt install git -y # Install Git
4. Deploying Budibase with Docker Compose
Create a directory for Budibase and clone the official Docker Compose files repository.
mkdir budibase # Create directory for Budibase
cd budibase # Go to directory
git clone https://github.com/Budibase/budibase-docker.git . # Clone Budibase Docker repository
Copy the example environment variables file and edit it.
cp .env.example .env # Copy .env example file
nano .env # Edit .env file
In the .env file, you will need to configure several important parameters:
DOMAIN=yourbudibasedomain.com: Replace with your domain. This is critical for HTTPS and access.SELF_HOSTED=true: Make sure this is set totrue.BB_MINIO_ACCESS_KEYandBB_MINIO_SECRET_KEY: Generate random, strong keys. For example, usingopenssl rand -hex 16.COUCHDB_USERandCOUCHDB_PASSWORD: Also generate strong credentials for the internal database.PORT=80: If you are using Caddy or Nginx for proxying, leave it at 80. If Budibase will be directly accessible, you can change it.
Example of key generation:
openssl rand -hex 16 # Generates a 32-character string
Save the .env file. Now you can start Budibase:
docker compose up -d # Start Budibase in the background
This command will download all necessary Docker images (Budibase, CouchDB, MinIO, Caddy) and start them. The process may take several minutes depending on your internet connection speed.
Check the status of running containers:
docker compose ps # Show status of running containers
You should see all services (budibase, couchdb, minio, caddy) in running status.
Budibase Configuration and HTTPS
After successfully starting the Budibase containers, the next step is to configure access via your domain with HTTPS. Budibase Docker Compose by default includes Caddy, which automatically manages Let's Encrypt certificates and proxies requests to Budibase.
1. DNS Setup
Before Caddy can obtain an SSL certificate, you need to configure a DNS record (A-record) for your domain, pointing to your VPS's IP address. For example:
| Record Type | Name | Value |
|---|---|---|
| A | yourbudibasedomain.com | YOUR_VPS_IP_ADDRESS |
| A | www.yourbudibasedomain.com | YOUR_VPS_IP_ADDRESS |
Wait some time for DNS changes to propagate globally (usually from a few minutes to an hour).
2. Automatic HTTPS Configuration with Caddy
If you have correctly configured the .env file with your DOMAIN and DNS records, Caddy should automatically obtain and configure an SSL certificate. You do not need to manually edit the Caddyfile, as it is generated based on Budibase environment variables. However, you can view it if problems arise.
The Caddyfile is located in the ./caddy/Caddyfile directory relative to your Budibase directory. In a standard configuration, it looks approximately like this:
{
# Global options
email [email protected] # Specify your email for Let's Encrypt notifications
}
http://{$DOMAIN}, https://{$DOMAIN} {
# Set the root for static files (if any) - not strictly necessary for Budibase proxy
root /app/public
# Enable gzip compression
encode gzip
# Reverse proxy to the Budibase service
reverse_proxy budibase:10000
# Log requests to stdout
log {
output stdout
format json
}
}
Make sure you have specified your email for Let's Encrypt notifications in the .env file:
# .env
# ...
[email protected]
# ...
Once the DNS records have updated, Caddy will automatically request certificates. You can check Caddy's logs to ensure the process was successful:
docker compose logs caddy # View Caddy logs
Look for messages related to Let's Encrypt and successful certificate acquisition. If there are errors, check DNS and ensure ports 80 and 443 are open in your firewall.
3. Budibase Initialization
Open your domain in a browser (e.g., https://yourbudibasedomain.com). You should see the Budibase welcome screen, where you will be prompted to create an administrator account. Fill out the form, create a strong password, and log in.
Congratulations! Your Budibase is installed and ready to work with HTTPS.
4. Operational Check
Perform a few checks to confirm correct operation:
-
HTTP/HTTPS Accessibility:
curl -v https://yourbudibasedomain.com # Check HTTPS accessibilityThe output should show HTTP/2 200 OK and SSL certificate information.
-
Docker Container Status:
docker compose ps # Ensure all containers are running -
Budibase Logs:
docker compose logs budibase # Check logs of the main Budibase serviceLook for error messages or warnings.
Backups and Maintenance
Regular backups and timely maintenance are critically important for any production system, including Budibase. This ensures the safety of your data and the stable operation of the platform.
1. What to Back Up
For Budibase on Docker Compose, the following components need to be backed up:
- CouchDB Data: The main Budibase database, containing application metadata, users, and configurations.
- MinIO Data: The file storage (images, documents) used by Budibase.
- Configuration Files: The
.envfile anddocker-compose.yml.
2. Simple Auto-Backup Script
We will create a simple script that will archive the necessary data and copy it to a secure location. As an example, we will use tar for archiving and rsync for copying to a remote server (or S3-compatible storage).
Create the file backup_budibase.sh in the /opt/budibase-backup/ directory:
sudo mkdir -p /opt/budibase-backup # Create directory for script and backups
sudo nano /opt/budibase-backup/backup_budibase.sh
Script content:
#!/bin/bash
# --- Configuration ---
BACKUP_DIR="/opt/budibase-backup/data" # Local directory for temporary backups
BUDIBASE_COMPOSE_DIR="/home/budiuser/budibase" # Path to the directory with docker-compose.yml
REMOTE_HOST="user@your_backup_server_ip" # Remote server for storing backups
REMOTE_PATH="/path/to/remote/budibase_backups" # Path on the remote server
DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="budibase_backup_${DATE}.tar.gz"
# --- Creating directories ---
mkdir -p "$BACKUP_DIR" || { echo "Error: Failed to create $BACKUP_DIR"; exit 1; }
# --- Creating CouchDB backup (via Docker volume) ---
echo "Creating CouchDB backup..."
docker compose -f "$BUDIBASE_COMPOSE_DIR/docker-compose.yml" cp couchdb:/opt/couchdb/data "$BACKUP_DIR/couchdb_data" || { echo "Error: Failed to copy CouchDB data"; exit 1; }
# --- Creating MinIO backup (via Docker volume) ---
echo "Creating MinIO backup..."
docker compose -f "$BUDIBASE_COMPOSE_DIR/docker-compose.yml" cp minio:/data "$BACKUP_DIR/minio_data" || { echo "Error: Failed to copy MinIO data"; exit 1; }
# --- Copying configuration files ---
echo "Copying configuration files..."
cp "$BUDIBASE_COMPOSE_DIR/.env" "$BACKUP_DIR/" || { echo "Error: Failed to copy .env"; exit 1; }
cp "$BUDIBASE_COMPOSE_DIR/docker-compose.yml" "$BACKUP_DIR/" || { echo "Error: Failed to copy docker-compose.yml"; exit 1; }
# --- Archiving all data ---
echo "Archiving data..."
tar -czf "$BACKUP_DIR/$BACKUP_FILE" -C "$BACKUP_DIR" couchdb_data minio_data .env docker-compose.yml || { echo "Error: Failed to archive data"; exit 1; }
# --- Deleting temporary directories ---
rm -rf "$BACKUP_DIR/couchdb_data" "$BACKUP_DIR/minio_data" "$BACKUP_DIR/.env" "$BACKUP_DIR/docker-compose.yml"
# --- Sending backup to remote server ---
echo "Sending backup to remote server $REMOTE_HOST:$REMOTE_PATH..."
rsync -avz "$BACKUP_DIR/$BACKUP_FILE" "$REMOTE_HOST:$REMOTE_PATH" || { echo "Error: Failed to send backup to remote server"; exit 1; }
# --- Cleaning up local backups (keep only the last N) ---
echo "Cleaning up old local backups (older than 7 days)..."
find "$BACKUP_DIR" -type f -name "budibase_backup_*.tar.gz" -mtime +7 -delete
echo "Backup completed successfully: $BACKUP_DIR/$BACKUP_FILE"
Make the script executable:
sudo chmod +x /opt/budibase-backup/backup_budibase.sh
3. Scheduling Backups with Cron
Add the script to the Cron scheduler for automatic execution. For example, for a daily backup at 02:00 AM:
crontab -e
Add the following line to the end of the file:
0 2 * * * /opt/budibase-backup/backup_budibase.sh >> /var/log/budibase_backup.log 2>&1
This line will run the script daily at 02:00 and write the output to the log file /var/log/budibase_backup.log.
4. Where to Store Backups
It is extremely important to store backups separately from the main server. Options:
- External S3-compatible service: AWS S3, DigitalOcean Spaces, Backblaze B2. For this, you will need to configure
s3cmdor a similar tool in the backup script. - Separate VPS: As shown in the
rsyncexample. Ensure that SSH key authentication is configured on this VPS for the user running the script. - Local storage synchronized with the cloud: For example, Nextcloud running on a separate server, or synchronization with Google Drive/Dropbox via special clients.
Never store the only copy of your backups on the same server as the main service!
5. Updates
Keeping Budibase and the underlying system up to date is critical for security and receiving new features.
-
OS Update: Regularly run system update commands.
sudo apt update && sudo apt upgrade -y # Update OS packages sudo apt autoremove -y # Remove unnecessary packages sudo reboot # Reboot after kernel update (if necessary) - Docker Update: Updates along with OS packages.
-
Budibase Update:
To update Budibase to a new version, you need to stop the containers, pull the latest changes from the Git repository, and start them again.
cd /home/budiuser/budibase # Go to Budibase directory docker compose down # Stop all Budibase containers git pull origin main # Pull latest changes from Budibase Docker repository docker compose pull # Pull new Docker images for Budibase docker compose up -d # Start Budibase with new imagesIt is recommended to perform Budibase updates during a "maintenance window," after making a full backup. Database migrations may sometimes be required, which happen automatically when a new version of Budibase is launched, but it's best to be prepared for potential issues.
Troubleshooting + FAQ
Even with the most careful installation approach, problems can arise. Here are common questions and their solutions.
Cannot connect to Budibase via domain name. What to check?
First, check the DNS records for your domain. Ensure that the A-record points to the correct IP address of your VPS. Use dig yourbudibasedomain.com or nslookup yourbudibasedomain.com to verify. Then, make sure that ports 80 and 443 are open in your firewall (sudo ufw status). Check Caddy logs (docker compose logs caddy) for errors when obtaining the Let's Encrypt SSL certificate. Caddy might not have been able to obtain the certificate due to an incorrect DNS record or blocked ports.
Budibase containers are not starting or are constantly restarting.
Check the logs of each container individually: docker compose logs budibase, docker compose logs couchdb, docker compose logs minio. Often, the problem lies in configuration errors in the .env file (e.g., incorrect keys, ports) or insufficient resources (RAM). If Budibase runs out of memory, it may shut down. Ensure that your VPS meets the minimum system requirements, especially for RAM.
What to do if I forgot my Budibase administrator password?
Budibase does not provide a direct way to reset the password externally. You will need to access the internal CouchDB data. The safest way is to use CouchDB utilities to create a new user or change an existing user's password. This requires deep knowledge of CouchDB and is not recommended without experience. The easiest way is to restore from a backup, if one was made before the password was lost, or to reinstall Budibase if there is no data yet.
What is the minimum suitable VPS configuration for Budibase?
For test environments or a very limited number of users (1-5) with a few simple applications, a VPS with 2 CPU cores, 4 GB RAM, and 50 GB SSD will be minimally suitable. This will be sufficient for basic functionality. However, for stable production operation with active use, 4 CPU cores, 8 GB RAM, and 100-200 GB SSD are recommended to avoid performance issues and provide room for data growth.
What to choose — VPS or dedicated for this task?
For most Budibase deployment scenarios (up to 50-100 active users, dozens of applications, moderate data volumes), a VPS will be the optimal choice in terms of price/performance ratio. A dedicated server should only be considered for very high loads, critical performance requirements without "noisy neighbors," working with terabytes of data, or the need for specific hardware (e.g., RAID arrays for maximum disk subsystem fault tolerance).
Errors occurred during Budibase update, the platform is not starting.
If Budibase does not start after git pull and docker compose up -d, try the following steps: 1. Check the logs of all containers (docker compose logs [service_name]). 2. Try clearing the Docker cache: docker system prune -a (caution, this removes all stopped containers, unused images, networks, and build cache). 3. If a backup exists, restore the previous working version. 4. Check the official Budibase GitHub repository for breaking changes in new versions.
How to scale Budibase if the VPS can no longer cope?
Scaling Budibase on a single server is limited. If you hit the performance ceiling of your VPS, there are several paths: 1. Increase the resources of the current VPS (vertical scaling). 2. Migrate Budibase to a more powerful dedicated server. 3. For horizontal scaling, Budibase requires a more complex architecture (e.g., CouchDB cluster, external S3 storage, multiple Budibase instances behind a load balancer), which goes beyond a simple Docker Compose deployment and requires orchestration like Kubernetes.
Conclusions and Next Steps
You have successfully deployed Budibase on your VPS, configured secure HTTPS access, and implemented a backup system. Now you have a powerful foundation for building internal applications, fully controlled by you and tailored to your needs.
What to do next?
- Create your first application: Start with a simple application for task management, a customer database, or inventory to get familiar with the Budibase interface and its capabilities.
- Integrate with existing data: Connect Budibase to your current databases (PostgreSQL, MySQL, MongoDB) or external APIs to start building applications based on real data.
- Explore advanced features: Master workflow automation, custom component creation, and deep integration with other services to maximize the platform's potential.