rubix-deploy

New Rubix server — full install flow. Tested on Debian 13.

Repository: https://gitea.dialer.work/swissdatabase/rubix-deploy
App releases: https://gitea.dialer.work/swissdatabase/rubix/releases

0) SSH on a new VPS (from your PC)

Tested on Debian 13 (Trixie).

wget -O bootstrap-vps-ssh.sh https://gitea.dialer.work/swissdatabase/rubix-deploy/raw/branch/main/bootstrap-vps-ssh.sh

chmod +x bootstrap-vps-ssh.sh

./bootstrap-vps-ssh.sh

ssh <your-host-alias>

1) Download Rubix (on the VPS)

Debian 13 VPS (see step 0).

wget -O install-rubix.sh https://gitea.dialer.work/swissdatabase/rubix-deploy/raw/branch/main/install-rubix.sh

chmod +x install-rubix.sh

sudo ./install-rubix.sh

The script will:

1. apt update / upgrade, install tools, Docker (docker.io) + Compose v2 plugin (apt or GitHub on Debian)
2. Ask for your Gitea token (if GITEA_TOKEN is not already exported)
3. Create /home/www/callcenter and download the latest rubix release

Optional: specific version sudo ./install-rubix.sh v1.1.10
Optional: other path sudo RUBIX_INSTALL_PATH=/opt/rubix ./install-rubix.sh

2) Configure .env and start stack

While editing .env, set your domain values (RUBIX_DOMAIN_CMS, API/DB/Mail hosts, aliases) and make sure DNS A/AAAA records for those hosts point to this server (manage records at your registrar/DNS provider).

cd /home/www/callcenter/deploy/docker

cp .env.example .env

nano .env

Set at least: GITEA_REGISTRY_PULL_TOKEN (same token as step 1), GITEA_REGISTRY_PULL_USER, MYSQL_ROOT_PASSWORD, DB users/passwords, COMPOSE_PROFILES, domains, RUBIX_STORAGE_ROOT.

COMPOSE_PROFILES — comma-separated list of Docker stacks that sudo ./up.sh installs and keeps running. Default:

COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk

Profile	Container role
cms	Rubix call center web app (Apache/PHP)
mysql	Percona/MySQL database
phpmyadmin	DB admin UI (db.* vhost)
asterisk	Dialer / SIP

Optional profiles (add to the same line when needed):

Profile	Container role
metabase	Enhanced analytics at /callcenter/admin/analytics — while logged into Rubix, opening analytics in a new tab signs you into Metabase automatically (no second login). Dashboards respect work groups and permissions so each group admin sees only their data
mailcow	Full mail server stack (Mailcow); set MAILCOW_HOSTNAME and mail.* DNS

Examples:

COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk,metabase
COMPOSE_PROFILES=cms,mysql,phpmyadmin,asterisk,metabase,mailcow

Start:

cd /home/www/callcenter/deploy/docker

sudo ./up.sh

Single service: sudo ./up.sh mysql / cms / asterisk

Extra / Manual operations (optional)

Use these only when you need manual control (classic install via sudo ./up.sh already handles normal startup flow).

SQL migrations (fresh database)

cd /home/www/callcenter/deploy

sudo RUBIX_MYSQL_VIA_DOCKER=1 MYSQL_DOCKER_CONTAINER=rubix-mysql ./apply_sql_migrations.sh

Use your RUBIX_MYSQL_CONTAINER from .env. Existing server: restore MySQL datadir under RUBIX_MYSQL_DATA instead.

CMS HTTPS (when DNS is ready)

cd /home/www/callcenter/deploy/docker

docker-cms-certbot

Dialer

docker-asterisk

/etc/init.d/callcenter2 restart

Updates (app already installed)

cd /home/www/callcenter/deploy

./rubix_deploy_from_release.sh vX.Y.Z

Software Update (CMS admin panel)

After the stack is running, app updates can be done from the call center admin UI instead of SSH.

1) Grant permission to the admin user

The user who should run updates needs the Software Update permission enabled.

1. Log in as a superadmin (or another user who can edit permissions).
2. Open Management → Users Permissions (search: Users Permissions).
3. Select the target admin user.
4. Enable Software Update (gru) and save.

Without this checkbox, the Software Update panel is hidden and API calls return No Software Update permission (gru).

2) Open the panel

Management → Software Update (popup). The panel reads the installed version from VERSION, compares it to the latest release on Gitea (RUBIX_GIT_RELEASE_URL in /etc/rubix/.env), and shows deploy logs.

Required in /etc/rubix/.env:

• RUBIX_GIT_RELEASE_URL — e.g. https://gitea.dialer.work/swissdatabase/rubix/releases/latest
• RUBIX_GIT_TOKEN or GITEA_REGISTRY_PULL_TOKEN — token with read access to releases
• RUBIX_PANEL_HOST_UP_ENABLE=true — show host reload buttons (default: enabled)

Logs (under the install path):

• deploy/rubix_deploy.log — panel ZIP deploy
• deploy/rubix_host_up.log — host up.sh (when triggered)

Use ↻ Reload logs to refresh both logs in the panel.

3) Update options

Button	What it does
Install latest release	Downloads the release ZIP from Gitea, syncs files into /home/www/callcenter, runs SQL migrations from the CMS container. Does not restart Docker services on the host.
Install latest release and trigger reload	Same as above, then queues deploy/docker/up.sh on the host (root cron, ~1 min). Restarts/refreshes the stack: Docker compose, MySQL users, firewall, host cron, SQL migrations via docker exec, certbot, fail2ban, etc.
Trigger reload (up.sh only)	No ZIP deploy. Only queues deploy/docker/up.sh on the host (root cron). Use when code is already up to date but you need containers/services refreshed and DB migrations applied on the host. Available even when no newer release exists.

Install latest release = code + migrations inside CMS.
Trigger reload = full host stack reload via sudo ./up.sh (panel cannot run it directly; root cron picks up the request).

Manual equivalent on the server:

cd /home/www/callcenter/deploy
./rubix_deploy_from_release.sh vX.Y.Z          # panel “Install latest release”
# or
cd /home/www/callcenter/deploy/docker && sudo ./up.sh   # panel “Trigger reload”

Multi-company / multi-branch layout

Rubix is built around work groups so you can separate companies, branches, or teams on one platform.

One server, several tenants — run a single Rubix stack and assign users, campaigns, permissions, and data to different groups. Each group admin and their agents see only what their group is allowed to access.

One server per tenant — install a full Rubix stack on a separate VPS for each company or branch when you want hard isolation (own database, domains, and ops).

Choose based on scale, compliance, and how much sharing you want on the same host.

Metabase analytics and groups

With the metabase profile enabled, analytics at /callcenter/admin/analytics is tied to the same Rubix session (auto sign-in when you open it from Rubix).

Metabase questions and SQL are adjusted so results respect allowed work groups: a group admin sees dashboards and query output for their groups only, not the whole server. Superadmins retain broader visibility according to Rubix permissions.