Environments
An environment is a place a release runs, such as staging, production, or a customer's own
installation. Logmarq keeps which release each environment runs, as a person or your pipeline
reported it. That answers "what's in production?" and "who has this bug?" without asking around.
Why you would use it
A support ticket arrives: something broke in production after the last deployment. Before anyone can look, someone has to establish which version production is on, and whether staging already has the fix. With environments recorded, the project page says what each one runs, since when, and who said so, and Compare shows exactly which pull requests, issues, and artifact digests are on staging but not yet in production.
The same record answers the wider questions later: which environments still run a version with a known bug, and what an environment has to do when it next upgrades.
When you don't need it
If you ship one continuously deployed service and your deployment tool already shows what runs where, recording it again in Logmarq adds little. Environments earn their place when several versions are live at once, or when the question comes from someone who cannot read your deployment tool.
How it works in Logmarq
- Environments. A project starts with one,
production. Name others in the project's configuration. - Deployments are reports. Each says where it came from: a person, the pipeline that rolled it out, something that observed it, or unspecified. Your deploy job can record one with the record action or the CLI inside the image, naming its run.
- Each environment has a state, with its reason. Reported (the latest report, still fresh), stale (older than the environment's freshness window), conflicting (reports that disagree, with every side listed), or unknown (nothing recorded).
- Mistakes are corrected, not edited. A wrong report is retracted or replaced, and stays on record with the correction beside it. Every environment keeps its history.
- Manual steps. What an environment has to do on upgrade beyond deploying, such as taking a backup or setting a flag, can be written down once and settled per environment. A pipeline can ask whether an environment is ready before it deploys, and stop itself.
What it will not claim
- A recorded deployment is not verified runtime state. It is what the ledger was told, with its source and age. Logmarq does not inspect your clusters or servers.
- Stale and unknown stay visible. An old report is not presented as current, and an environment with nothing recorded says so rather than guessing.
- Logmarq never deploys. Recording a deployment changes nothing where the software runs, and Logmarq refuses no deployment it is told about.
Get started
Open a project: each environment where nothing is reported offers the latest release in one click (Mark v1.2.3 as running here). Environments in the sidebar shows every project at once.
To keep it current without anyone remembering, let the deploy job report it. The record action for GitHub Actions takes the environment the job rolled out to and records the deployment with the run's address; any other pipeline calls the API with an API token. From the server, the CLI inside the image does the same:
docker exec logmarq logmarq release deploy <project>@<version> production --source pipeline
Related pages
Customers and the deployment map · Release lines · Release records