# Architecture introduction

> How a SummerCMS application is built: one Go binary with compiled plugins, a headless JSON API, an embedded admin SPA and console commands.

A SummerCMS application is one Go binary. The framework modules, the application's plugins, the embedded admin SPA and every console command are compiled into it. You deploy that file and its `config/` directory; nothing is installed or loaded at runtime.

## One binary, compiled plugins

A plugin is a Go package that implements `party.Plugin` and registers itself from `init` with `party.Register`. The application lists the plugins it uses in its `summer.yaml` manifest. `summer build` reads that manifest, generates `plugins.gen.go` (a blank import for every plugin and the ordered `PluginIDs` list) and a `main.go`, then runs `go build`. Adding or removing a plugin is a rebuild, not a runtime switch.

This replaces the WinterCMS plugin directory scan. The compiler checks every plugin against the interfaces it claims to implement, and a missing dependency fails the build or the boot, never a later request.

## Headless by design

SummerCMS serves a JSON API and the admin SPA. It has no themes, CMS pages or frontend components: the public site is a separate application that calls the API and subscribes to realtime channels. The admin is a compiled Vue application that [boardwalk](/docs/api/boardwalk.md) serves from the binary, and it reads the admin API that [cabana](/docs/api/cabana.md) builds from each plugin's `fields.yaml` and `columns.yaml`.

## The framework modules

Each framework module is one Go package under `modules/`, documented by its README and its API reference page.

| Concern | Modules |
|---------|---------|
| Plugins and the container | [party](/docs/api/party.md), [pact](/docs/api/pact.md), [backpack](/docs/api/backpack.md), [festival](/docs/api/festival.md), [compass](/docs/api/compass.md) |
| HTTP | [surf](/docs/api/surf.md), [towel](/docs/api/towel.md), [wire](/docs/api/wire.md), [bouncer](/docs/api/bouncer.md), [wristband](/docs/api/wristband.md), [fetchguard](/docs/api/fetchguard.md) |
| Data | [lagoon](/docs/api/lagoon.md), [beachcomber](/docs/api/beachcomber.md) |
| Admin | [cabana](/docs/api/cabana.md), [boardwalk](/docs/api/boardwalk.md) |
| Services | [phrasebook](/docs/api/phrasebook.md), [postcard](/docs/api/postcard.md), [conga](/docs/api/conga.md), [lighthouse](/docs/api/lighthouse.md), [flare](/docs/api/flare.md) |
| Console and tooling | [bonfire](/docs/api/bonfire.md), [tide](/docs/api/tide.md) |

## What runs where

Two programs carry console commands:

- The `summer` tool is the developer CLI. You install it once with `go install ./cmd/summer`. It builds and watches applications (`summer build`, `summer dev`), scaffolds plugins and their parts (`summer make:plugin`, `summer make:model` and the other `make:` commands), records and replays API parity fixtures and builds these docs.
- The application binary, for example `bin/hello`, carries the runtime commands: `serve`, `migrate`, `route:list`, `queue:work`, `admin:create` and the commands its plugins add. It is what you run in production.

Some `summer` commands, such as `summer migrate` and `summer serve`, run the matching command of the application binary in the current application directory, building it first when it is missing. The [Installation](/docs/setup/installation.md) guide walks through both programs.