Servers and sites as one system.

A cluster joins servers and sites into one infrastructure. Master and slave roles, a shared .env, database access between servers and a firewall that configures itself.

Connect a server All features

7 days free
No card required
Payment in rubles

Shop cluster

› A release on every server of the cluster

web-01master
worker-01slave
worker-02slave
db-01MySQL · Redis

2: roles in the topology: master defines the settings, slave receives them
4: kinds of templates: daemons, cron, .env and deploy script
1click: to deploy a template to every slave server
0: MySQL and Redis ports open to the whole internet

Cluster members

Add a server — the network configures itself.

A cluster is not a label on servers: it wires them together. Every change to the member list starts background tasks on all members, and a single unreachable server never blocks the rest.

Firewall between servers

UFW rules are rebuilt automatically on every member: MySQL and Redis ports are open only to the cluster's server addresses, not to the whole internet.

What gets updated UFW 3306 6379

MySQL across servers

A database server binds MySQL to its own network address by itself — never to 0.0.0.0. A site on a neighboring server connects with no manual setup.

What gets updated bind-address 127.0.0.1 server IP

Redis across servers

A shared Redis for cache and queues: the list of allowed addresses follows the cluster's member list. A new server gets access, a removed one loses it.

What gets updated allowed IPs UFW

Sites join with their server

Sites on a server you add are attached to the cluster automatically, and sites created later inherit it. Remove the server and its sites are detached.

What gets updated existing new

Roles and templates

Configure once — apply to all.

Roles decide where templates go: master is the source of settings, slave servers receive them. Variables resolve per server and site, and you see the result before applying.

Topology

Assign a role right on the map

The Topology tab is a live map of the cluster: each server's load, its sites and how many templates are deployed on it. The role is switched right on the node.

Master is the source of settings, slave receives the templates
Saving links every master to every slave
CPU, RAM and disk of every server in real time
A node's sites and their SSL state

TopologyShop · 4 servers

Links: 2

ServerRole

web-01Laravel

master slave —

worker-01Worker

master slave —

worker-02Worker

master slave —

db-01Database

master slave —

Every master is linked to every slaveSave roles

Daemons and cron

A daemon or a cron job on every server

Define a queue worker, Horizon or a scheduled command once. The panel writes the Supervisor config or the crontab entry on every slave server and shows the real status for each one.

Supervisor daemon templates bound to a server type
Presets: Queue worker, Horizon, Reverb, Scheduler
Update and restart on all servers with one button
Removal from servers: the template itself stays in the cluster

Daemon templatesShop · to every slave server

New template

horizonphp artisan horizon

Update all

Deployed to · targets: worker

worker-01

running

worker-02

running

Cron templates

queue-restart0 */6 * * *

2 servers

Deployed to slave servers2 / 2

.env

One .env template for every site

The template is rendered separately for each slave site: the domain, database name and master server address are filled in automatically. Before applying you see which keys will change on every site.

Variables and conditions: server.role, website.domain, master.server.ip
Modes: replace the whole file or change only the keys from the template
Load the master site's current .env as a starting point
Unchanged sites are skipped

Env syncShop · .env template

merge

APP_NAME={{ project.name }}
DB_HOST={{ master.server.ip }}
{% if server.role == 'slave' %}
QUEUE_CONNECTION=redis
{% endif %}

Preview per slave

worker-01

applied · 2 keys

worker-02

up to date — will skip

1 applied · 1 skippedApply

Synchronized deploys

One push — a deploy across several sites

Chain sites together: after every deploy of the master site — from the panel, a webhook or MCP — the linked sites are deployed too. They share a deploy script as well: a cluster template with variables resolved per site.

Link master → dependent sites
Configurable delay between deploys
Zero-downtime and run history on every site
Deploy script template: load the script from master and apply it to slave sites

Synchronized deployshop.example.com

Links: 2

Site and serverDelay

shop.example.comweb-01 · master

source

shop.example.comworker-01 · slave

immediately

shop.example.comworker-02 · slave

30 s

Follows: 2 sitesAdd

New node

One more server — with a single form.

The Add location button connects one more server as a worker node of the cluster: it clones the master site and applies, in order, everything already configured in the cluster.

The server is provisioned with the Worker preset and joins the cluster as a slave
.env is copied from master: the database and Redis point at cluster servers
The node's own .env keys are applied on top of the copied ones
A smoke test at the end: database and Redis reachable, Horizon consuming

Servers and worker nodes

ams-1198.51.100.24 · Worker · Shop cluster

In service

Cluster automation6 / 6

Provisioning, Worker presetslave
Site clone and .env from mastermain
Cluster .env templatemerge
Deploy script from the template
Horizon, daemons and cronSupervisor
Smoke test: database, Redis, Horizon

The node is consuming queue jobsHorizon

In the panel 203.0.113.21 Connect done in 4 min 52 s

Bring your servers into one system.

Servers, sites, roles and shared data — under one roof, with automatic synchronization.

Start for free For agencies

7 days free
No card required
Human support