Cordice
Open Cordice
Self-hosting

Run it yourself.

Every part of Cordice is published under the AGPL-3.0, including the compose files we deploy from. Not a community edition with the interesting parts removed — the same code, on your machine, answering to you.

The deployment stack Read the source

Before you start

This is functional and it is what we run, but it is not a turnkey install. The stack is documented well enough to follow and not yet well enough to run unattended: expect to read the compose file, and expect an evening rather than ten minutes.

One thing to know before you commit: your instance serves its own web client, and that is the client for it. Our Android app is built with these hosts compiled in and cannot be pointed somewhere else, and there is no iOS build yet. People on your instance will be using a browser.

We would rather say that here than have you find out at two in the morning.

What it takes

One machine, and a few things pointed at it.

What comes up

Nine services of ours, and seven anybody's.

Our images are built from this repository and tagged localhost/cordice/*. Nothing is pulled from a registry we do not control except plain infrastructure — which means there is no image in the stack you cannot rebuild yourself from source you can read.

Only Caddy and the voice ports are published. The databases, the queue and the object store are reachable from inside the container network and nowhere else.

Built from this repository

  • api
  • events
  • web
  • autumn
  • january
  • pushd
  • gifbox
  • crond
  • voice-ingress

Ordinary infrastructure

  • MongoDB
  • Redis
  • RabbitMQ
  • MinIO
  • LiveKit
  • Stalwart
  • Caddy
The shape of it

Three commands, and the reading between them.

  1. Prepare the machine

    bootstrap.sh sets up the host and nothing else — user, ssh, firewall, swap, podman. It is safe to run again: every step checks the current state first, so re-running it on a working machine is how you confirm the machine still matches what you believe about it.

  2. Write the configuration

    generate_config.sh takes your domain and writes the config files, filling in any secret that is not already there. It never overwrites one that is, which is what makes it safe to run after a change.

  3. Bring it up

    podman-compose up -d. Caddy fetches certificates on the first request, so the domain has to point at the machine before this looks like it worked.

Where you stand

Your instance is yours, and it is not us.

What we do not cover

The parts we deliberately left out.

Guides for putting this behind somebody else's reverse proxy, for MongoDB substitutes, and for connecting third-party clients came with the project we forked and described a deployment that is not ours. We removed them rather than leave them to be trusted.

So the stack describes one way of running Cordice: the way we run it. Other ways are possible and none of them are documented here, because we would be guessing.

If you get stuck

Self-hosting questions belong in discussions, where the answer stays findable for whoever asks next. If something in the stack is actually broken, that is an issue.

We cannot support your deployment, and we will not pretend otherwise. What we can do is answer questions about the thing we wrote.