Budibase on AWS User Guide

Overview

This image runs Budibase, the open source low code platform for building internal tools, admin panels, approval apps and CRUD apps over your existing data. Teams design applications visually, connect them to their own databases and APIs, and publish them to their organisation, replacing spreadsheets and manual processes with real applications.

Budibase runs from the official single self-host container, which bundles everything the platform needs in one place: Apache CouchDB for app definitions and metadata, MinIO for object and file storage, Redis for cache and session, the application and worker services, and an internal nginx. The whole stack is supervised by one systemd service, budibase.service, and only port 80 is published to the host. Every backing service stays inside the container and is never exposed on any external interface.

All application state, the CouchDB databases and the MinIO object store, lives on a dedicated EBS data volume mounted at /var/lib/budibase, independently resizable and separate from the operating system disk. It is captured into the image and re-provisioned on every instance, so your apps survive container restarts, reboots and resizes.

On the first boot of every deployed instance, a one-shot service generates unique per-instance secrets (JWT, internal API key, and the CouchDB, MinIO and Redis passwords), creates a per-instance administrator account with a random password, and records the sign-in details in /root/budibase-credentials.txt with mode 0600. No shared or default credentials ship in the image.

Prerequisites

Before you deploy this image you need:

• An Amazon Web Services account where you can launch EC2 instances
• IAM permissions to launch instances, create security groups, and subscribe to AWS Marketplace products
• An EC2 key pair in the target Region for SSH access to the instance
• A VPC and subnet in the target Region, with a security group allowing inbound port 22 from your management network and inbound port 80 (and 443 once you add TLS) from the networks your users will reach Budibase on
• An instance type with at least 8 GB of memory; the bundled database, object store and cache need roughly 4 GB of headroom, so m5.large or larger is recommended
• The AWS CLI (version 2) installed locally if you plan to deploy from the command line

Step 1: Launch the Instance from the AWS Marketplace

Sign in to the AWS Management Console, open the EC2 service, and select Launch instance. Under Application and OS Images choose AWS Marketplace AMIs and search for Budibase. Select the cloudimg listing and choose Select, then Continue on the subscription summary.

Pick an instance type of m5.large or larger. Choose your EC2 key pair under Key pair (login). Under Network settings select your VPC and subnet, and either create or select a security group that allows inbound port 22 from your management network and inbound port 80 from the networks your users use. Leave the root volume at the default size or larger; the image adds a separate data volume for application state automatically.

Select Launch instance. First boot initialisation takes a minute or two after the instance state becomes Running and the status checks pass, while the container starts and seeds the administrator account.

Step 2: Launch the Instance from the AWS CLI

The following block launches an instance from the cloudimg Budibase Marketplace AMI into an existing subnet and security group. Replace ami-0example00000000 with the AMI ID shown on the Marketplace listing, <key-name> with your EC2 key pair name, <subnet-id> with your subnet ID, and <security-group-id> with a security group that opens ports 22 and 80 as described above.

aws ec2 run-instances \
  --image-id ami-0example00000000 \
  --instance-type m5.large \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --block-device-mappings '[{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":30,"VolumeType":"gp3"}}]' \
  --metadata-options 'HttpTokens=required' \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=budibase}]'

Step 3: Connect and Retrieve the Admin Password

Connect over SSH with the key pair you selected and the public IP address of the instance. The SSH login user depends on the operating system of the AMI variant you launched:

ssh -i <key-name>.pem ubuntu@<public-ip>

The per-instance administrator email, password and URL are written to a root-only file on the instance. Read it with sudo (the value is unique to your instance and never leaves it):

sudo cat /root/budibase-credentials.txt

The file contains the sign-in URL, the administrator email (admin@cloudimg.local) and the generated password. Store the password somewhere safe.

Step 4: First Sign-in

Open http://<instance-public-ip>/ in your browser. Budibase presents its sign-in screen.

Sign in with the administrator email admin@cloudimg.local and the password from the credentials file. You land on the workspace home, which shows your tools, automations and apps alongside quick actions to create new ones.

Step 5: Connect a Data Source

Budibase works on top of your existing data. Open Data tables in the left navigation and choose Add new data source. You can create a table in the bundled Budibase database, upload a CSV or JSON file, or connect to an external datasource such as PostgreSQL, MySQL, MS SQL Server, Oracle, MongoDB, Redis, Amazon S3, Google Sheets and more.

Once a data source is connected, design screens and forms over it visually, add automations that react to record changes, and publish the app to your users from the Publish action in the top right.

Step 6: Verify the Service Is Healthy

Budibase is managed by systemd as budibase.service, which runs the single self-host container. To confirm the stack is up, connect over SSH and run:

sudo systemctl is-active budibase.service
sudo docker ps --filter name=budibase --format "{{.Names}}  {{.Status}}"
for i in $(seq 1 60); do
  CODE=$(curl -s -o /dev/null -w '%{http_code}' http://localhost/api/system/status || echo 000)
  [ "$CODE" = "200" ] && break
  sleep 5
done
echo "system status: HTTP ${CODE}"

A healthy instance reports:

active
budibase  Up 19 minutes (healthy)
system status: HTTP 200

The /api/system/status endpoint returns HTTP 200 with a small JSON body ({"health":{"passing":true},"version":"3.39.26"}) whenever CouchDB, MinIO, Redis and the application services are all up.

Step 7: Enable HTTPS with Let's Encrypt

Budibase is served over plain HTTP on port 80. For production, terminate TLS in front of it. The simplest single-instance option is an nginx reverse proxy with a free Let's Encrypt certificate. Point a DNS record at the instance, open port 443 in the security group, then on the instance install and run certbot for your domain:

sudo apt-get update
sudo apt-get install -y nginx certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

For a load-balanced or highly available deployment, terminate TLS on an AWS Application Load Balancer or Amazon CloudFront distribution in front of the instance instead, and forward traffic to port 80.

Step 8: Backups and Maintenance

All Budibase state lives under /var/lib/budibase on the dedicated data volume. The most reliable backup is a point-in-time EBS snapshot of that volume, which captures the CouchDB databases and the MinIO object store together.

sudo systemctl stop budibase.service
# take an EBS snapshot of the data volume from the AWS console or CLI, then:
sudo systemctl start budibase.service

You can also schedule automatic snapshots with Amazon Data Lifecycle Manager. To move to a newer Budibase release, take a snapshot first, then follow the upstream upgrade notes for the single self-host image.

Step 9: Scaling and Operations

The single self-host image is designed for a single instance. To handle more users, resize the instance to a larger type, and grow the /var/lib/budibase EBS volume as your data and file storage grow. Keep the instance behind a TLS terminator and restrict port 80 to that terminator's security group so the application is never reached over plain HTTP from the public internet.

Support

This image is published by cloudimg with 24/7 technical support by email and live chat, with a one-hour average response for critical issues. Our engineers help with deployment, TLS termination, backups, user management, connecting external data sources and scaling.

Email: support@cloudimg.co.uk

All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.