SummerCMS

A new dawn in content management

A content management framework for Go, inspired by WinterCMS. Plugins, the admin SPA and console commands compile into a single binary.

Read the docs Alpha 0.2 is out

The SummerCMS admin: the Journal posts list with search, filters, categories and publish dates

WHY SUMMER

A content framework, built the Go way.

One binary

Plugins are Go packages, compiled in and type-checked at build time. You deploy one binary.

YAML-driven admin

Describe lists and forms in fields.yaml and columns.yaml. An embedded SPA renders them.

Headless by design

A JSON API declared route by route, plus realtime channels. Build the public site in whatever frontend you like.

THE ADMIN

Describe it in YAML. Get this.

Every screen below comes from the Journal plugin’s fields.yaml. Field types, tabs, spans and relations are compiled at boot, and the embedded admin renders them. No frontend code.

models/post/fields.yamlabridged

title:
    type: mltext
    span: left
    required: true
slug:
    type: mltext
    span: right
    preset:
        field: title
        type: slug
content:
    type: mlmarkdown
    size: huge

Translatable title, slug preset and a Markdown editor with preview.

Editing a Journal post: title, slug and the rendered Markdown preview

WHAT'S IN THE BOX

The services a content app needs.

Admin SPAEmbedded in the binary, driven by each plugin’s YAML.Models & migrationsGORM structs with fill, validation and pagination helpers.Routing & authRoute groups, named middleware, tokens and OAuth.Queued jobsDispatched inside the caller’s transaction.RealtimeBroadcast model changes to subscribed clients.SearchSearchable models, synced after commit.Mail & pushPlugin mail templates and push notifications.ConsoleScaffolding, scheduler, workers and your own commands.

FAMILIAR IF YOU KNOW WINTERCMS

The same ideas, in Go.

Plugins still register and boot, require each other, ship migrations and admin YAML. If you know WinterCMS, you'll feel at home.

See the full concept map →

SummerCMS owes its design to WinterCMS. If you're happy on PHP, WinterCMS is a great home. Thank you to the Winter team and community. Visit wintercms.com

IN WINTERCMSIN SUMMERCMS

Plugin.phpparty.Plugin

version.yaml + updates/pact.HasMigrations

Eloquent modelsGORM + lagoon

fields.yaml / columns.yamlSame YAML, compiled at boot

routes.phppact.HasRoutes

Event::listen / firefestival.Bus

Artisan commandsbonfire.Command

WHY GO

PHP served us well. Running it at scale didn’t.

We built client projects on OctoberCMS and WinterCMS for years, and the plugins we still rely on started there. What wore us down wasn’t the framework. It was keeping it fast in production.

Workers that eat the server

Every PHP request takes a whole worker that boots the app from scratch. Under traffic the worker pool grows until it takes over the machine’s memory and CPU.

Scaling out wasn’t enough

Adding servers moved the problem without solving it. Busy sites still needed load balancing and careful tuning of how many workers each server runs.

Caching as a survival strategy

To serve traffic safely we leaned on Redis and other caching layers, which means more services to run, more invalidation bugs and more to monitor.

One process, always warm

A SummerCMS app is one long-running Go process. Concurrent requests are cheap goroutines, and config, routes and the compiled admin YAML stay in memory. You add a cache when you need one, not to keep the site standing.

If PHP works for you, WinterCMS is still a great home, and if you know it, you already know most of SummerCMS.

GET STARTED

Build your first app.

Go 1.27PostgreSQL 15+

Alpha 0.2 is for early adopters. APIs may change before 1.0.

Installation guide Source

terminal

# create an app and install the summer CLI$ curl -fsSL https://summercms.io/new | bash -s -- demo# start PostgreSQL in Docker$ cd sm-demo-app$ docker compose up -d --wait# build, migrate and serve$ summer build$ summer migrate$ summer serve