Quickstart

This page takes you from nothing to recorded releases with drafted notes. You need Docker and a GitHub account that can read the repository you want to record. No configuration file is needed.

Step 1: Run the image

docker run -d --name logmarq -p 127.0.0.1:8080:3000 \
  -v logmarq-data:/var/lib/logmarq \
  ghcr.io/dekglas/logmarq:<version>

For anything you keep, pin the image by digest instead: ghcr.io/dekglas/logmarq@sha256:<digest>.

One container serves the web app and the API and keeps its database in one file on the logmarq-data volume. It applies its database migrations when it starts. There is no separate database to provision.

Step 2: Create the first administrator

Open http://localhost:8080. A new installation asks for its first administrator, who then invites everyone else. The First run checklist on the Projects page shows the remaining steps and ticks each one from what Logmarq has recorded, not from what you clicked.

Step 3: Connect GitHub

Connect GitHub offers two ways in. Neither needs a configuration file.

Create a GitHub App for this Logmarq (recommended). Logmarq sends GitHub an App manifest; you confirm it on GitHub, choose the repositories the App may read, and come back connected. The App asks for read access only: contents, metadata, pull requests, and issues. When GitHub can reach your Logmarq's address, the App also delivers tag pushes and published releases, so new versions record themselves.
Use a personal access token, for evaluation.

Publishing notes to GitHub and freezing branches stay off until you add those permissions to the App yourself. The Connect GitHub page links to where you add them and says which needs which.

Step 4: Add a project

Projects → Add project takes the repository's owner/name. Logmarq reads its logmarq.yaml when the repository has one; otherwise it drafts a configuration from the repository: its default branch, the shape of its version tags, GitHub Issues as the tracker, and the release assets and container images it finds. Review the draft and register it. Nothing needs committing to your repository; the project's Configuration page changes it later, as a form or as YAML.

Step 5: Import its releases

A new project opens on Import existing releases. It previews every version it found, with when each was made and whether GitHub published it as a release, and asks which versions shipped: a tag alone does not say a version reached anyone. Each version is recorded oldest first and compared with the one before it.

To start small, record only the newest tag. When an earlier tag exists, Logmarq compares the two, so the first record already lists the pull requests, commits, and issues between them.

ScreenshotThe Import existing releases dialog listing versions with their dates, whether each was published on GitHub, and the question of which versions shipped

Step 6: Approve the notes

Logmarq drafts internal notes for each release as it records it, with a template unless you configure a model. Open a release: Approve a draft that is right as it stands, or edit it and tick what customers should see, then create the customer notes. Copy them as Markdown, plain text, or rich text into your chat, email, or wiki, or publish them to the GitHub release.

Step 7: Mark it released

A release moves from recorded to validating to released, or rejected, in its Lifecycle. Marked released, it counts as shipped everywhere Logmarq answers from, and the checklist is complete.

Where to go next

Release records: record new versions automatically, from a webhook or your pipeline.
Environments: say where each release runs.
Release notes: customer notes, public notes, and drafting with a model.