Budibase on Ubuntu 24.04 on Azure User Guide

Overview

Budibase is an open-source low-code platform for building internal tools, admin panels, approval workflows and CRUD applications on top of your existing data. This cloudimg image deploys the free self-hosted community build (Budibase 3.39.26, GPL-3.0 core) from the official single self-host container, which bundles everything a Budibase stack needs - Apache CouchDB, MinIO object storage, Redis and the Budibase app and worker services - inside one container fronted by its own internal nginx. The Budibase UI is served on port 80; every backing service stays inside the container. All application data is persisted on a dedicated Azure data disk, and a unique platform admin account is generated on the first boot of every VM. Backed by 24/7 cloudimg support.

What is included:

• Budibase 3.39.26 community build, deployed from the official budibase/budibase single self-host image
• The Budibase UI (builder, published apps and workspace portal) on :80, served by the container's internal nginx
• CouchDB, MinIO and Redis bundled inside the container - never exposed on the host, only port 80 is reachable
• A per-VM admin account generated on first boot and recorded in a root-only credentials file
• A dedicated Azure data disk at /var/lib/budibase for all CouchDB and MinIO state, captured into the image and re-provisioned on every VM
• budibase.service as a systemd unit, enabled and active
• 24/7 cloudimg support

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet + subnet in the target region. Standard_B4ms (4 vCPU / 16 GiB RAM) is the recommended size - the all-in-one Budibase stack (CouchDB + MinIO + Redis + app + worker) needs around 4 GiB of RAM to run comfortably. NSG inbound: allow 22/tcp from your management network and 80/tcp for the Budibase UI. Budibase serves plain HTTP on port 80; for production, terminate TLS in front of it (an Azure Application Gateway or Front Door, or a reverse proxy with your own certificate) using your own domain.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Budibase by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size (Standard_B4ms or larger); under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Review the dedicated data disk on the Disks tab, then Review + create -> Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name budibase \
  --image <marketplace-image-urn> \
  --size Standard_B4ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name budibase --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the service is running

Budibase runs as a single systemd unit that manages the container:

systemctl is-active budibase.service

It reports active. On first boot the VM generates per-VM secrets and a unique admin account, then starts the container.

Step 5 - Confirm the health endpoint

Budibase exposes an unauthenticated status endpoint that returns 200 once the stack is healthy. The first start pulls the bundled services up, so allow up to a couple of minutes on first boot:

for i in $(seq 1 40); do
  code=$(curl -s -o /dev/null -w '%{http_code}' -m 5 http://localhost/api/system/status)
  [ "$code" = "200" ] && break
  sleep 5
done
curl -s http://localhost/api/system/status

It returns a small JSON object reporting the platform status.

Step 6 - Retrieve your admin password

The admin password is generated uniquely on the first boot of your VM and written to a root-only file, alongside the admin email and URL:

sudo cat /root/budibase-credentials.txt

This file contains BUDIBASE_ADMIN_EMAIL (admin@cloudimg.local) and BUDIBASE_ADMIN_PASSWORD. Store the password somewhere safe.

Step 7 - Sign in to Budibase

Browse to http://<vm-public-ip>/ and sign in as admin@cloudimg.local with the password from Step 6.

After signing in you land on your workspace home, the starting point for building apps, automations and agents.

Open Data tables to connect a data source. Budibase ships with its own built-in database, or you can connect an existing PostgreSQL, MySQL, MS SQL Server, Oracle, MongoDB, CouchDB, Redis, Amazon S3, Google Sheets or REST API, then build screens and automations on top of it.

Invite your team from Invite users, assigning each person a role and generating a password for them - no external email server required.

Step 8 - Verify authentication from the command line

Budibase's login endpoint accepts the per-VM admin credentials and rejects a wrong password. Read the password from Step 6, then post it to the login API (replace <BUDIBASE_ADMIN_PASSWORD> with the value from your credentials file):

curl -s -o /dev/null -w '%{http_code}\n' \
  -X POST -H 'Content-Type: application/json' \
  -d '{"username":"admin@cloudimg.local","password":"<BUDIBASE_ADMIN_PASSWORD>"}' \
  http://localhost/api/global/auth/default/login

A correct password returns 200 and sets a session cookie; a wrong password returns 403. Because Budibase applies brute-force protection, avoid repeating failed attempts in quick succession.

Step 9 - Confirm data lives on the dedicated disk

All Budibase state (the CouchDB databases and the MinIO object store) is stored on the dedicated Azure data disk so it survives container restarts, reboots and resizes:

findmnt /var/lib/budibase
docker ps --filter name=budibase --format '{{.Names}} {{.Status}}'

The mount is backed by a separate Azure data disk captured into the image and re-provisioned on every VM, and the container reports as running (and healthy once fully started).

Building your app

Budibase is designed to be the fastest way to build internal tools. Connect a data source (its built-in database or one of your existing systems), design screens with the drag-and-drop builder, add automations that trigger on data changes or a schedule, and publish the app to your users. See the Budibase documentation for data sources, components, automations and role-based access.

Maintenance

• Admin and users: manage users and roles from the workspace portal; invite teammates and generate passwords for them from Invite users.
• Backups: snapshot the /var/lib/budibase data disk, which holds all CouchDB and MinIO state.
• Per-VM secrets: the platform secrets (JWT, CouchDB, MinIO, Redis) and the admin password are generated per VM at first boot and stored in /etc/budibase/budibase.env (root-only). Do not reuse them across VMs.
• TLS: Budibase serves plain HTTP on port 80; front it with TLS and your own domain (an Azure Application Gateway or Front Door, or a reverse proxy) before production use.
• Restarting: the platform is a single systemd unit - use sudo systemctl restart budibase to restart the container.
• Security patches: unattended-upgrades remains enabled so the OS continues to receive security updates automatically.

Support

cloudimg provides 24/7 expert support for this image. Contact support@cloudimg.co.uk.