Your logs are sensitive. We build like it.
Logs hold customer identifiers, internal hostnames and the occasional secret that slipped through. Here is how Logmast keeps that data contained.
Tenant isolation
- Every database operation runs inside a transaction bound to a single workspace.
- PostgreSQL row-level security enforces that boundary in the database itself.
- The runtime database role owns no tables and cannot bypass the policies.
- Background workers take the same scoped path as the API.
Credentials and access
- Services use ingest-only tokens that can write events and nothing else.
- Read and control tokens are separate, named, and revocable.
- People sign in with a password and a TOTP second factor.
- Owner, member and viewer roles limit who can change alert rules, mutes and tokens.
Data handling
- Configured fields are redacted before an event is written anywhere.
- Events are committed synchronously and deduplicated for 90 days.
- Expired evidence is excluded from every read; physical cleanup and backup expiry follow their own schedules.
- Public APIs and the console use HTTPS. The application database connection stays on host loopback.
Operations
- The service ships as an immutable container image built from a pinned toolchain.
- Secrets live in a managed secrets store, never in images or source.
- Database backups are restored in full as a routine drill, not only in emergencies.
- Failed processing can be replayed from stored receipts without duplicating alerts.
Report a vulnerability
If you believe you have found a security issue in Logmast, email security@logmast.comwith steps to reproduce. We will confirm receipt within two business days and keep you updated until it is resolved.
Please do not access other customers' data or degrade the service while testing.
Have a security review to get through?
Tell us what your team needs to see. We will walk through the isolation model and answer your questionnaire during the pilot.