Owncast: the develop branch is the default clone and the container build sits outside CI

Cloning the default branch gives you unreleased code, and the project says so

The default branch for this repository is develop, not master and not main. The project puts a warning about it directly in the build instructions: the develop branch is always the most up-to-date state of development and this may not be what you always want. If you want the latest released stable version you are told to check out the tag related to that release, with v0.0.13 given as the example for anyone who wants the source from before the v0.1.0 development cycle. That instruction is the single most important operational fact in the repository, and the fact that develop is what a plain clone lands on makes it easy to miss. Nothing stops you from running a branch that is mid-cycle. The release list makes the gap visible: v0.2.4 on 2026-01-10, v0.2.5 on 2026-04-11, then v0.3.0 on 2026-09-03, with the last push to the repository on 2026-10-26. The consequence for an operator is that your upgrade decision is a tag choice.

The setup steps ask for Go 1.24 while go.mod requires 1.26.2

Two versions of the same requirement appear in the same repository. The backend build instructions say to install the Go toolchain, 1.24 or above. The module file at the root declares module github.com/owncast/owncast and pins go 1.26.2, with a large require block underneath it. The lower bound in the prose will not get you a working build if your toolchain resolver honours the module directive, and the mismatch is not cosmetic: the dependency list pins specific minor versions, including github.com/mattn/go-sqlite3 v1.14.47, github.com/gorilla/websocket v1.5.3, github.com/nareix/joy5, and github.com/pressly/goose/v3 v3.27.2. The prerequisites listed before the toolchain also explain why the build is not pure Go. You are told to have a C compiler installed, either GCC or a Musl-compatible compiler, and ffmpeg, which lines up with the CGO-backed SQLite driver and the transcoding the server performs. So the honest prerequisite list is the union of both sources, not the shorter one.

One binary, one admin path, and two exposed ports

Owncast is described as a single user live video streaming and chat server, and the run path reflects that. From source the sequence is short enough to copy as is:

git clone https://github.com/owncast/owncast
cd owncast
go run main.go

That lands you on a web interface at http://yourserver:8080 with the admin at http://yourserver:8080/admin, after which you point your broadcasting software at the server and start streaming. The frontend is a separate project in the web directory, installed with `npm install` and started with `npm run dev`. Compatibility is stated in terms of protocol rather than product: anything that uses RTMP to broadcast to a remote server should work, and OBS, Streamlabs, and Restream have all been used with it. The container definition makes the shape concrete. It builds a static binary from golang:alpine with CGO_ENABLED=1, stamps config.GitCommit, config.VersionNumber, and config.BuildPlatform into the link step, copies the result into alpine:3.24.0 with ffmpeg, ffmpeg-libs, and ca-certificates, creates an owncast user and group at uid 101, makes /app/data, and exposes 8080 and 1935. The broadcaster needs the RTMP ingest port; viewers need the web port or the address of a reverse proxy serving it.

The Dockerfile states outright that container builds are not in continuous testing

The first comment lines in the repository's Dockerfile are a disclaimer, not a greeting. It says the file has been provided for the sake of convenience, that the functionality of the containers built based on it is not a part of continuous testing, and that patches to keep it up to date are always welcome. It then directs you to the Earthfile for the recipes used in official builds. That division matters in practice. The convenience file is what most people read first, and it is the one with no automated guarantee behind it, while the Earthfile plus its .earthlyignore hold the recipes used in official builds. That disclaimer applies to containers built from the convenience Dockerfile, not automatically to official images. The Earthfile used for official builds includes a startup sanity check on linux/amd64; check the release workflow and test the image and platform you intend to use.

ActivityPub, WebAssembly and web push land in the same binary

The module dependency list is where the real scope of the server shows up. Alongside the obvious pieces, github.com/go-fed/httpsig and code.superseriousbusiness.org/activity sit in the require block, which is the ActivityPub signing and activity vocabulary stack, and the tree carries a FEDERATION.md and a .well-known/ directory to match. github.com/extism/go-sdk v1.7.1 with github.com/tetratelabs/wazero v1.12.0 pulls a WebAssembly runtime into the process, and there is a pluginhost/ directory at the top level. github.com/SherClockHolmes/webpush-go handles browser push, github.com/oschwald/geoip2-golang handles IP data, github.com/microcosm-cc/bluemonday sanitizes HTML, and github.com/grafov/m3u8 works with HLS. That is a large dependency surface for a single self-hosted service that a streamer exposes to the internet. The project does acknowledge the risk profile with a dedicated security policy at docs/SECURITY.md, and there is a separate reporting address, [email protected], which the docs state is the security-reporting address and explicitly not the place to use the general support contacts.

SQLite state and backup coverage

There is no external database in this design. Persistence runs through github.com/mattn/go-sqlite3 v1.14.47, migrations are handled by github.com/pressly/goose/v3 v3.27.2, and the repository carries db/, persistence/, and models/ directories alongside sqlc.yaml, which is the configuration for generating queries rather than writing them by hand. github.com/schollz/sqlite3dump is also in the dependency list, and the container creates /app/data before handing over to the unprivileged owncast user. Put those together and the operational picture is a service that keeps its state locally in SQLite. The sqlc and openapi.yaml plus redocly.yaml combination adds a second wrinkle: queries and API types are generated, so hand edits to generated output are lost the next time the generator runs.

The official backup guide says Owncast writes an hourly database backup by default. This does not include every file under data/, such as custom assets and plugin data, so include the entire data directory in your backup plan and test restoration.

Contribution needs six tool binaries before lint can run at all

The Makefile manages development tools itself rather than assuming they are on your PATH. There is a bin directory as GOBIN, and the install-tools target builds six binaries into it: lefthook, golangci-lint, gofumpt, sqlc, oapi-codegen, and shellcheck, each through a go install -C tools invocation against a separate tools module. The install-hooks target depends only on the lefthook binary and runs lefthook install --force, and the target itself echoes a message about patching hooks with a self-healing bootstrap, meaning the hook files are regenerated if the bin/lefthook binary has gone missing. The rest of the target list is lint, fmt, sqlc, api-generate, build, test, and clean. Linting is configured separately through .golangci.yml and .prettierignore, commit messages through commitlint.config.js, dependencies through renovate.json, and translations through crowdin.yml. There are also AGENTS.md and CLAUDE.md files in the root, which suggests the project expects agents to read repository instructions. The consequence is that the first thing a contributor does is compile the toolchain, not write code.

No native Windows server, so Windows operators are routed to WSL2

A note in the build section is unambiguous about platform support: Owncast currently does not natively support Windows servers, and Windows users can use Windows Subsystem for Linux (WSL2) to install it, with details in contrib/owncast_for_windows.md. It has direct consequences. A Windows user is not running a native service, they are running a Linux userspace with a network translation layer in front of it, and the container exposes 8080 and 1935, so both the web interface and the RTMP ingest port have to be reachable from outside whatever the translation layer does to them. If your only option is a Windows server, this is the constraint to price in before anything else. The alternative worth reading is the Docker route, with the caveat from its own Dockerfile that the image build is not covered by continuous testing.

Editorial conclusion

Owncast suits a streamer who already runs a server, wants chat and streaming from one MIT licensed binary, and is willing to serve RTMP to the internet themselves. The documented Windows route uses WSL2; check current platform support and the testing of the specific container image you deploy. Before committing, clone the tag matching your intended version instead of the default branch, confirm your Go toolchain against the 1.26.2 line go.mod actually requires, decide how you will back up the SQLite database, and read docs/SECURITY.md so you know what counts as a vulnerability before you report one.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes