Documentation

Visit /register and sign up with your email address. You can also sign in with GitHub if your organization uses it.

On first login you will be prompted to create an organization — this is the shared workspace for your team.

Go to Dashboard → New Environment and give it a name like production or staging. You can add an optional cluster name for Kubernetes setups.

Install the CLI (see CLI Reference) and run:

kollaber login --api https://kollaber.io --email you@example.com --password yourpassword
kollaber deploy --env production --service api --version v1.0.0

Head back to the dashboard — your deploy event will appear in the timeline immediately.

Each environment has its own timeline. Events are sorted newest-first and show the event type, service name, timestamp, and any attached metadata (version, author, etc.).

The timeline polls for new events every 10 seconds — no refresh needed. A coloured badge indicates the event type:

• DEPLOY — a service release recorded via the CLI, CI, or webhook
• ALERT — an alert ingested via webhook
• NOTE — a manual note added by a team member

Click any event to expand it. Use the comment box to leave context — root cause, rollback decision, follow-up ticket, anything. Comments are timestamped and attributed to the author.

Go to Settings → Members to invite teammates via email. Each member can be assigned one of four roles:

• Owner — full control including billing and org deletion
• Admin — manage members, environments, and all events
• Member — create events and comments
• Viewer — read-only access to the timeline

Go to Settings → Notifications. Check the event types you want to be notified about and optionally enter a notification email address:

• Deployments — emailed when a deploy event is recorded
• Alerts — emailed when an alert event is recorded
• Notes — emailed when a note is added to the timeline

The Notification email field lets you receive alerts at a different address than your account email — useful for shared inboxes or on-call aliases. Leave it blank to use your account email.

Preferences are saved per organization. Members who have not configured preferences receive no emails by default.

When any event is created (via the CLI, webhook, or UI), Kollaber fires all configured channels asynchronously — email recipients, the Slack webhook, and the Teams webhook all receive a notification without blocking the API response.

Go to Settings → Slack and paste an Incoming Webhook URL. To get one:

1. Open your Slack workspace's App Directory and install Incoming Webhooks
2. Choose a channel and click Add Incoming Webhooks integration
3. Copy the generated webhook URL and paste it into Kollaber

Use the Send test message button to verify delivery. Slack messages include the event type (with an emoji), the service name, and the environment.

Go to Settings → Teams and paste an Incoming Webhook URL. To get one:

1. Open the target Teams channel and click ··· → Connectors
2. Search for Incoming Webhook and click Configure
3. Give it a name, click Create, then copy the webhook URL

Teams messages are sent as colour-coded MessageCard payloads — blue for deploys, red for alerts, purple for notes.

Only owners and admins can save or clear the Slack and Teams webhook URLs. Members and viewers can see whether a webhook is configured but cannot change it.

Install with Go:

go install github.com/urbangeeks/kollaber/cmd/kollaber@latest

Or download a pre-built binary from the downloads page.

Set the KOLLABER_API environment variable to point at your self-hosted instance. Defaults to http://localhost:8080.

Authenticate and save a token to ~/.kollaber/config.json.

# Email + password
kollaber login --api https://kollaber.io --email you@example.com --password yourpassword

# CLI token from Settings → API Tokens (for GitHub OAuth users)
kollaber login --api https://kollaber.io --token <your-token>

List all environments in your organization.

kollaber envs

Record a deploy event.

kollaber deploy \
  --env production \
  --service api \
  --version v1.2.3

Drop a manual note into the timeline — useful for maintenance windows or on-call observations.

kollaber note --env production "Rolling back v1.2.3 due to 5xx spike"

View recent events for an environment.

kollaber timeline --env production --limit 20

The watcher runs as a Deployment inside your cluster using a ServiceAccount with read-only access to Deployments and Pods. Install one release per cluster:

helm install kollaber-watcher ./charts/kube-watcher \
  --set kollaber.env=prod \
  --set kollaber.api=https://kollaber.io \
  --set kollaber.token=<cli-token>

Get your CLI token from the dashboard under Settings → CLI Token.

Install a separate Helm release for each cluster, pointing each one at the matching Kollaber environment:

helm install kollaber-watcher-prod    ./charts/kube-watcher --set kollaber.env=prod    ...
helm install kollaber-watcher-staging ./charts/kube-watcher --set kollaber.env=staging ...

Events from each cluster will appear in their respective environment timelines in the dashboard.

If you manage secrets externally (Vault, Sealed Secrets, External Secrets Operator), skip secret creation by pointing at your own:

# Your secret must have a key named "token"
kubectl create secret generic my-kollaber-token --from-literal=token=<cli-token>

helm install kollaber-watcher ./charts/kube-watcher \
  --set kollaber.env=prod \
  --set kollaber.api=https://kollaber.io \
  --set kollaber.existingSecret=my-kollaber-token

The watcher binary also works outside the cluster using your local kubeconfig — useful for testing:

go install github.com/urbangeeks/kollaber/cmd/kube-watcher@latest

kube-watcher \
  --kubeconfig ~/.kube/config \
  --env prod \
  --api https://kollaber.io \
  --token <cli-token>

The binary tries in-cluster config first. If it is not running inside a pod it falls back to --kubeconfig (or ~/.kube/config by default).

POST https://kollaber.io/webhooks/events

No authentication required on the webhook endpoint. Payloads are normalized into the events table.

Add a step at the end of your deploy job:

- name: Notify Kollaber
  run: |
    curl -sS -X POST https://kollaber.io/webhooks/events \
      -H "Content-Type: application/json" \
      -d '{
        "type": "deploy",
        "service": "${{ github.repository }}",
        "environment_id": "${{ secrets.KOLLABER_ENV_ID }}",
        "metadata": {
          "version": "${{ github.sha }}",
          "author": "${{ github.actor }}",
          "ref": "${{ github.ref }}"
        }
      }'

Store your environment UUID as a GitHub secret named KOLLABER_ENV_ID. Find it on the Dashboard under your environment settings.

Any JSON body with the following shape is accepted:

{
  "type":           "deploy" | "alert" | "note",
  "service":        "your-service-name",
  "environment_id": "uuid-of-environment",
  "metadata":       { /* any key-value pairs */ }
}

• Kubernetes cluster with Helm 3
• PostgreSQL 14+ (or use the in-cluster option below)

helm install kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --create-namespace \
  --set secret.jwtSecret=$(openssl rand -hex 32) \
  --set externalDatabaseUrl=postgres://user:pass@your-postgres:5432/kollaber \
  --set ingress.enabled=true \
  --set ingress.host=kollaber.mycompany.com

Save the generated jwtSecret — it must stay the same across upgrades or existing sessions will be invalidated.

If you don't have an external database, deploy one with Bitnami's chart:

helm install postgres oci://registry-1.docker.io/bitnamicharts/postgresql \
  --namespace kollaber \
  --set auth.username=kollaber \
  --set auth.password=changeme \
  --set auth.database=kollaber

Then use the service name as the hostname:

--set externalDatabaseUrl=postgres://kollaber:changeme@postgres-postgresql:5432/kollaber

Create a GitHub OAuth App at github.com/settings/developers. Set the callback URL to https://kollaber.mycompany.com/auth/github/callback, then pass the credentials:

--set secret.githubClientId=your_client_id \
--set secret.githubClientSecret=your_client_secret

If not set, GitHub OAuth is disabled and users log in with email/password only.

Kollaber uses email OTP for login — users receive a 6-digit code to sign in. Delivery is resolved in this order:

For production installs, configure SMTP:

--set secret.smtpHost=smtp.yourprovider.com \
--set secret.smtpPort=587 \
--set secret.smtpUser=notifications@mycompany.com \
--set secret.smtpPassword=your_password

SMTP uses STARTTLS on port 587. Port 465 (implicit TLS) is not supported. Most providers — Gmail, SendGrid, Mailgun, Exchange — support port 587.

--set secret.webhookSecret=your_hmac_secret

If not set, webhook payloads are accepted without signature verification.

If your cluster uses Istio instead of a standard ingress controller, disable the Ingress resource and enable Istio routing:

helm install kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --create-namespace \
  --set secret.jwtSecret=$(openssl rand -hex 32) \
  --set externalDatabaseUrl=postgres://user:pass@your-postgres:5432/kollaber \
  --set ingress.enabled=false \
  --set istio.enabled=true \
  --set istio.host=kollaber.mycompany.com

With TLS:

--set istio.tls.mode=SIMPLE \
--set istio.tls.credentialName=kollaber-tls

The gateway selector defaults to istio: ingressgateway. Override with --set istio.gatewaySelector.istio=my-gateway if your gateway pod uses a different label.

helm upgrade kollaber oci://ghcr.io/urbangeeks/charts/kollaber \
  --namespace kollaber \
  --reuse-values

Use --reuse-values to keep your existing secrets and config. Migrations run automatically on every upgrade.

Query parameters for GET /events: environment_id (required) and limit (default 50).