Federation
Qbix servers can forward events to each other. Any Q::event() call can be handled locally or routed to a remote server — same dispatch path, same handler signature, transparent to the app code.
How it works
1. Server identity. On first run, each server generates a self-signed certificate. The SHA-256 fingerprint is the server’s identity — like SSH known_hosts, no certificate authority needed.
2. Discovery. Every server exposes /.well-known/qbix.json with its fingerprint, endpoints, and installed plugins.
3. Event forwarding. Configure which events route where:
{
"Q": {
"handlersUsingRemote": {
"Users/login": {"baseUrl": "https://auth.example.com"},
"Streams/stream": {"baseUrl": "https://streams.example.com"}
}
}
}
When Server A receives a Users/login event, it forwards it to auth.example.com/Q/event via HMAC-signed POST. The receiving server verifies the signature, dispatches locally, and returns the result. Loop prevention is built in — a forwarded event is never re-forwarded.
4. Signing. All inter-server requests are HMAC-SHA1 signed over recursively key-sorted data. Compatible with the Qbix Platform — servers upgrading keep working without changes.
Cluster Replication
Events configured for replication automatically broadcast to all peers after the local handler runs.
Configuration
{
"Q": {
"cluster": {
"replicate": [
"swarm/task_add",
"swarm/task_update",
"swarm/task_delete",
"swarm/message"
]
}
}
}
Start a second server with the first as a peer:
PEERS=http://localhost:4001 php qbixserver.php --port=4002
Both servers now replicate the configured events. Create a task on one — it appears on the other. Each server has its own SQLite database; the events keep them in sync.
Self-healing sync
New servers (or restarted servers) pull full state from a peer on startup via /api.php?action=sync. Kill a node, restart it — it catches up automatically. No manual intervention, no ops playbook.
Trust levels
| Level | What it means |
|---|---|
| Pinned peer | Fingerprint stored in config. Events accepted, signature verified. For known partners. |
| Owned server | Shared Q.internal.secret. Full trust, can forward user sessions. For your own infrastructure. |
| Public | No fingerprint, just HTTPS. Read-only access via /.well-known/qbix.json. For open APIs. |
Deploy
Push your app to a remote server with one command:
Deploy configuration
php qbixserver.php --deploy=production
{
"targets": {
"production": {
"host": "myserver.com",
"user": "deploy",
"path": "/var/www/myapp",
"key": "~/.ssh/deploy_key",
"dirs": ["web", "handlers", "classes", "config"]
}
}
}
Rsyncs each directory to the remote. If the remote runs Qbix Server, it can hot-reload on deploy. Servers can also be managed from the Panel’s Servers tab.