Choose a deployment
All three options run the same software. They differ in how it is started, updated and scaled.
If you have no reason to choose otherwise, pick Docker on one server. If your operations team already runs a Kubernetes platform and wants to operate Collabase with the tools it uses for everything else, pick Kubernetes. Both are fully supported.
Operating system and platform
macOS and Windows with Docker Desktop (WSL2) work for testing and local trials. They are not a production platform.
CPU and memory
Size for the people who work at the same moment, not for the number of accounts. Sizing & scaling maps concurrent users to resources. These are the starting points:
On Docker the installer stops below 2 GB of RAM or 10 GB of free disk space. Below 4 GB, turn off live collaboration.
On Kubernetes, reserve the same capacity in the namespace. What each part of Collabase may use is listed in What runs in your cluster. The memory limits of all parts add up to a little more than 11 GB, and the memory the scheduler reserves for them is about 1.75 GB. Normal operation uses far less than the limits. The limits protect the cluster from a runaway process.
Run a test system and a production system as separate installations, each with its own database. A test system can use the minimum.
Storage
The total is about 45 GB on Kubernetes and 20 GB on a single Docker server, plus backups. On Kubernetes you need a default storage class that provides
ReadWriteOnce volumes, or you set the class per volume. Watch the disk and grow it before it fills. Hosting & Architecture lists what takes space.
Database
Collabase ships with its own PostgreSQL. If your organization runs a managed or central database service instead, it must provide:- PostgreSQL 16 or later
- The
pgvectorextension, which Collabase enables withCREATE EXTENSION vectorduring installation. The database user that installs needs the right to do this, or your database team enables the extension once beforehand. - A database and a user that owns it
pgvector, Collabase does not start. Check this with your database team before you decide to use an external database.
Network
Inbound
Nothing else is reachable from outside. The parts of Collabase talk to each other on an internal network.
Live collaboration uses a WebSocket connection on the same address under
/collab. A load balancer or proxy in front of Collabase must pass WebSocket upgrades through, and must allow uploads of at least 32 MB.
Outbound
Collabase makes only the connections you set up. Allow the ones you use:Collabase verifies its licence key on the server and needs no connection to Collabase for it. Usage telemetry is off until an administrator agrees to it, and an administrator can switch it off again.
Certificates
An internal address such as
collabase.company.local needs a certificate from your own certificate authority, and every browser must trust that authority.
Container images
The Collabase images share one version number and are public, so pulling them needs no sign-in. Many organizations copy the images into an internal registry first. On Kubernetes, set the repository of each image in your values file, see Use your own image registry.
Optional integrations
These are set up in Collabase after installation. Plan them with your identity and mail teams in advance.Information for your operations team
If a team other than yours installs and maintains Collabase, agree on these points first.Related pages
Installation with Docker
Install on one Linux server.
Installation on Kubernetes
Install with the Helm chart.
Sizing & scaling
Match resources to your team.