Security and privacy
Logmarq stores release records and the integration configuration used to read them. Self-hosting gives you control of that deployment; it also leaves host security, backups, TLS and provider permissions with you. These controls describe the development implementation, not an independent security certification or a promise that every integration has been qualified with a live provider.
Sign-in and authorization
Local accounts have password hashing and opaque sessions. Viewer, editor and administrator roles control actions. User API tokens inherit current user authority; read-only and short-lived setup tokens have narrower duties. A setup token is not an administrator credential. Keep tokens out of command histories, URLs, screenshots and support reports, and revoke them when no longer needed.
The last active administrator is protected against accidental demotion or disablement. For federated identity or directory provisioning, use the exact configuration supported by your release; a provider claim does not independently grant a role. Changing sign-in configuration is not a substitute for removing a person's application access.
Provider access and external effects
Connect only the repositories and artifact sources the installation needs. The guided GitHub App starts with read access. Publishing notes and optional source-branch freezing are separate explicit actions that need additional provider permissions. Logmarq records deployments; it does not deploy the customer's software.
Configured integrations make outbound requests to their providers. Optional model drafting sends the selected drafting material to the configured model provider. Vulnerability scanning downloads definitions when enabled. Do not describe a self-hosted installation as making no outbound calls.
Stored data, secrets and public pages
The default deployment keeps its ledger in SQLite on the data volume; PostgreSQL is optional. Saved integration credentials are sealed, but database and key custody still matter. Protect the volume, the sealing key, environment files and backups. A database copy is sensitive even when some fields are encrypted. Keep backups and restore drills isolated from live provider writes.
Public project pages are explicit opt-ins. Review customer-facing release notes and artifact references before publication. An internal record, draft or source comparison is not automatically appropriate for public disclosure. Avoid credentials, customer data and private source details in notes, exports and response packages.
Exports deliberately omit some sensitive state, including saved provider credentials. Use the release's complete recovery guidance rather than assuming an export recreates a running instance.
Vulnerabilities and fixes
Report suspected vulnerabilities privately through the established security contact. Include the product version and a minimal reproduction; omit passwords, tokens, license keys, database dumps and confidential customer material. Security reporting is separate from support eligibility and carries no implied response-time guarantee.
Security fixes are delivered through new releases for the latest promoted supported release. Older-version backports or maintenance windows are not promised. Verify the replacement version's files and signature and follow its migration instructions; see upgrades and support.