SecureAnyCloud
Deployment guide

Budibase

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 SecureAnyCloud image deploys the free self-hosted community build (Budibase 3.39.26, GPL-3.0 core) from the official single self-host container. The container bundles everything a Budibase stack needs inside one container fronted by its own internal nginx: Apache CouchDB, MinIO object storage, Redis, and the Budibase app and worker services. The Budibase UI is served on port 80, and 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. The image is backed by 24/7 SecureAnyCloud support.

What you get:

  • 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, so 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 SecureAnyCloud support

Prerequisites

  • An active Azure subscription, an SSH key pair, and a VNet and 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 rules: 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 SecureAnyCloud, 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 select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:budibase-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name budibase \
  --image sac1647283583153:budibase-ubuntu-24-04:default:latest \
  --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

The command 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 brings 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

The endpoint returns a small JSON object that reports 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@sac.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@sac.local with the password from Step 6.

After you sign 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 is 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@sac.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. Budibase applies brute-force protection, so 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
sudo docker ps --filter name=budibase --format '{{.Names}} {{.Status}}'

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

Building your app

Budibase is designed to be the fastest way to build internal tools. To build an app:

  • 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.
  • 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. Before you run it in production, front it with TLS and your own domain (an Azure Application Gateway or Front Door, or a reverse proxy).
  • 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

SecureAnyCloud provides 24/7 expert support for this image. Contact sales@secureanycloud.com.

Deploy on Azure

Launch Budibase on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure