changelog.com: the podcast CMS its authors ask you not to fork

The CMS behind a podcast network, described plainly

changelog.com is the website of Changelog, a podcast network covering developer tooling, and this repository holds the content management system underneath it. GitHub reports the repository description as "Changelog makes world-class developer pods. This is our open source platform." and lists the topics as cms, elixir, hackers, hacktoberfest, phoenix, podcasting and postgresql.

The README is direct about scope. It opens with "This is the CMS behind changelog.com" and describes an Elixir application built on the Phoenix web framework, with Node.js handling static assets and PostgreSQL for persistence. This is therefore a server-rendered web application with a database, a front-end asset build step and a runtime that serves requests, not a static site generator and not a headless API. It also explains why the company open sourced it, giving three reasons: they depend on open source for their own work, Phoenix was young enough that there were few in-production open source sites to point at as examples, and their community of hackers would send bug reports and pull requests.

That reasoning has aged well as history. It is also the point at which the README stops being a current description of the system, which matters for anyone deciding how to use the code.

Why the README argues against forking it

The most valuable part of this README is the section that discourages you. Under the heading "Should I fork this and use it as a platform?" the answer begins "Probably not", and the text goes on to say this is not a general purpose podcasting CMS but one specific to Changelog and its needs, from design and layout through data structures and file hosting. The authors then offer their own strongest evidence against reusability: podcast names hardcoded into areas of the code, linked to a pinned commit of lib/changelog/buffer/buffer.ex, closing with the blunt verdict "Yuck."

That admission deserves respect rather than argument. A CMS that encodes a fixed set of podcast names into application logic has welded its content model to one editorial catalog, and the surrounding data structures follow from that decision. Anyone forking this starts by unpicking those assumptions before reaching any feature they actually wanted, so the setup cost exceeds the cost of starting from a general Phoenix application and building the parts you need.

The README also says what the code is good for: if you are building with Phoenix or want to, this is a place to poke around and see what one looks like when everything is wired together. It concedes the result is not perfect by any means but works. The one performance claim is a link to a 2016 tweet describing the site as "ridiculously fast" rather than a benchmark committed to the repository, so read it as an anecdote from the project's early years rather than as a measurement you can reproduce.

What the file tree says about how the team works

The root listing is the fastest way to size the project. Mix is present through mix.exs and mix.lock, application code sits in lib/, static files in assets/, and tests in test/. Around those sit the files that reveal a team's habits: .credo.exs for the Credo static analysis common in Elixir projects, .formatter.exs for formatting, coveralls.json for coverage reporting, and CONTRIBUTING.md for the contribution path.

Several entries are much newer than the project's public origin. mise.toml and mise.lock pin tool versions through the mise task runner, fnox.toml serves a similar purpose, and .devcontainer/ offers a container-defined development environment. There is a fly.io/ directory for deployment and a docker/ directory alongside it, plus a .claude/ directory that appears to hold AI agent configuration rather than application code. Any of these could shift the onboarding path you would have followed in 2016.

INFRASTRUCTURE.md at the root is a good sign, because deployment notes committed next to the code are how a team avoids tribal knowledge. VIBE.md is the less conventional of the two; its name does not describe its contents, and it is worth opening before you contribute, since files like that usually encode working norms that no other document states.

A local Postgres service short enough to read in one screen

Local setup is not described in prose, but compose.yml at the repository root is short enough to be the fastest explanation available. It defines one service named db, backed by postgres:16.12, publishing port 5432 to the host, storing data in a named volume, supplying credentials through environment variables, and checking health with pg_isready on a five second interval with five retries.

name: changelog

services:
  db:
    image: postgres:16.12
    ports:
      - "5432:5432"
    restart: unless-stopped
    volumes:
      - postgres-data:/var/lib/postgresql/data
    environment:
      POSTGRES_PASSWORD: postgres
      POSTGRES_USER: postgres
      POSTGRES_DB: changelog_dev
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

volumes:
  postgres-data:

Two details matter in practice. The database is named changelog_dev rather than the default postgres database, so application configuration expecting the default will not find its tables on the first run. And the healthcheck matters for sequencing: the Elixir application expects a database at boot, and a healthcheck that succeeds quickly is what lets a startup script or an orchestration step wait for the right moment instead of retrying blindly.

The rest of the environment is left to the tooling in the tree. With mise.toml, fnox.toml and .devcontainer/ all present, there are at least two supported routes into a working setup, and the devcontainer is likely the lower-friction one for anyone whose editor supports it.

Where the README and the repository disagree

GitHub reports the license for this repository as NOASSERTION, which is what the API returns when it cannot map a license to a recognised SPDX identifier, and yet the file tree contains a LICENSE file at the root. Both facts hold at once: a license file exists, and GitHub's licensee did not recognise it as one of the standard licenses it knows. Where the license affects your decision, read the LICENSE file rather than the API field. That habit generalises, because NOASSERTION appears in metadata for many repositories that carry perfectly ordinary licenses.

A second gap is generational. The homepage field points at a 2016 announcement post, and the README leans on that era's framing, including the observation that Phoenix is young enough in its lifecycle that there were not many in-production open source sites to use as examples. Meanwhile the working tree pins PostgreSQL 16.12 in compose.yml and carries a Fly.io deployment directory and a mise version lockfile. PostgreSQL 16 did not exist in 2016, so the README's account of the project's age no longer matches the dependencies it actually runs.

Neither side is false, and the useful move is to sort the claims by kind rather than to pick a winner. The README and the announcement post explain why the project was open sourced, which is a historical statement that never needed updating. mix.exs, compose.yml, INFRASTRUCTURE.md and the deployment directories describe how the application runs now. A reader who wants current information should weight the second group; a reader who wants to understand the reasoning should read the first.

Who this codebase rewards, and who it will frustrate

Judged on its own terms, this repository rewards a specific reader: someone learning or working in Phoenix who wants to see an application assembled end to end, with a database, an asset pipeline, tests, static analysis configuration and deployment files committed together and visible in one place. For that reader the value is legibility rather than reusability, and the README says as much in its section on what the project is good for.

Other readers get a warning instead. Someone wanting a podcast publishing platform has already been told why not to start here. Someone who needs clearly permissive licensing should treat the NOASSERTION value as a prompt to open the LICENSE file first. Someone hoping to depend on a version series will find that GitHub reports no releases for this repository at all, so there is no tagged version to pin, and consuming the code as a library is not a path the project supports.

The engagement numbers explain the shape of the whole thing. GitHub reports 2,768 stars, 247 forks and 24 open issues, a repository that is not archived, with a default branch of master and a most recent push on 2026-09-22. The README badge counts 31 contributors, and the contributor table credits people with code, documentation, infrastructure, design, financial and testing work. That mix is what a small publishing operation actually needs, and it also explains why the codebase stayed a working site instead of turning into a reusable framework. The pressure to open source came from the community; the pressure to generalise it never arrived.

Editorial conclusion

Read changelog.com as a worked example of Phoenix rather than as a starting point for a podcast CMS, and read the LICENSE file directly rather than the NOASSERTION value GitHub reports for it. The root contains compose.yml pinning postgres:16.12 with a pg_isready healthcheck and a changelog_dev database, which is the shortest route to a working local environment, and the repository publishes no tagged releases to depend on.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. thechangelog/changelog.com on GitHub