Trust at Glassmkr.
An open-source agent you can read. EU-stored data. A single operator you can email. Honest answers to the security questions you’d ask any monitoring vendor.
The agent you can read
The single most important thing we can do for your trust is let you read the code that runs on your servers.
Crucible is MIT licensed.
Source at github.com/glassmkr/crucible. You can audit every line before you install it. You can fork it. You can deploy your own modified version. You can extract specific parts of it for your own tooling. The license is the most permissive open-source license in common use.
The install script is ~150 lines of bash.
Read it at install.sh before piping it to bash. It does four things: download the Crucible binary, verify its signature against our published GPG key, install it as a systemd service, and register the node with your Glassmkr account. Nothing else.
Crucible runs as the glassmkr user, never root.
It cannot read files outside its operational scope. It cannot execute commands as other users. It writes to a single log file and a single state file in its own directory.
HTTPS only.
Crucible communicates with the Glassmkr dashboard over HTTPS only. No telemetry to third parties. No analytics provider. No phone-home outside the dashboard endpoint.
Two categories of data, nothing else.
Crucible ships exactly two categories of data: metrics and alert state. It does not ship logs. It does not ship command output. It does not ship secrets. It does not ship file contents. See the Data handling section for the full list.
Signed releases.
GPG signing key published at /.well-known/gpg-key.asc. Every Crucible release is signed with this key; the install script verifies the signature.
npm provenance.
Crucible publishes to npm with Trusted Publishing. The npm registry shows provenance for every published version (which GitHub Actions run produced it, which git commit, which workflow). Verify at npmjs.com/package/@glassmkr/crucible.
Data handling
What data leaves your server
- Metrics (CPU, memory, disk, network) as numeric values.
- Hardware sensor readings (SMART attributes, IPMI sensors, ECC counts, RAID/ZFS pool state) as structured values.
- Software state (failed systemd unit names, kernel vulnerability status, count of pending package updates).
- Server identification (hostname, IP address, distro, kernel version, DMI vendor/product where available).
- No logs, no raw command output, no application data.
Data storage
PostgreSQL + ClickHouse on a server in Amsterdam, Netherlands. EU jurisdiction. Daily encrypted backups stored on a second server in the same datacenter (also Amsterdam).
GDPR posture
Operated from the EU under Czech sole-trader registration. EU GDPR rules apply to your data. The Privacy Policy describes data processing, your GDPR rights (access, correction, deletion, portability), and the DSAR process.
Data retention
Alert state and metrics for active customers are stored indefinitely while the account is active. On account deletion, all customer data is purged within 30 days (some derived aggregations may persist in backups for up to 90 days before backup rotation purges them). DSAR deletion requests are honoured within the GDPR-required timeframe.
Who can access your data
A small team of engineers behind Glassmkr has the technical access required to operate the service. Access is not proactive: customer data is read only when needed for support tickets, debugging reported issues, or investigating service incidents.
What we do to manage this responsibly
- Engineer access to production systems is logged and retained for 90 days.
- We don’t sell customer data.
- We don’t share customer data with third parties beyond what’s required to deliver the service (Stripe for billing, Resend for email, the LLM inference layer on our own infrastructure).
- We sell monitoring as a service. That’s the entire business model.
If your security requirements include on-premise deployment or dedicated infrastructure, email [email protected] to discuss whether we can accommodate.
Security disclosure
If you’ve found a security issue in Crucible, the dashboard, or any Glassmkr infrastructure:
[email protected] (encrypted with the same GPG key as Crucible signing if you want; key at /.well-known/gpg-key.asc).
What to include
Description of the issue, reproduction steps if applicable, your contact information if you’d like to coordinate disclosure.
Response timing
We’ll acknowledge within 24 hours and provide an initial assessment within 72 hours.
Disclosure timeline
We coordinate disclosure timing with reporters. Default 90 days from acknowledgement to public disclosure, longer if needed for complex fixes, shorter if the issue is actively exploited.
Bug bounty
We don’t currently run a formal bug bounty program. Verified security findings get credited (with reporter’s permission) in our security disclosures, and we’ll send a thank-you bottle of whisky or equivalent.
Infrastructure provenance
What Glassmkr runs on:
Dashboard
SvelteKit application on a bare-metal Linux server in Amsterdam, behind Cloudflare. PostgreSQL + ClickHouse for storage. pgBackRest for PostgreSQL backups. Self-hosted on dedicated hardware, not a cloud VM.
AI assistant (Furnace)
Self-hosted Gemma 4 26B model on a single NVIDIA L4 GPU in Amsterdam, served via llama.cpp. No third-party LLM APIs (no OpenAI, no Anthropic, no Google). Your alert data does not leave EU jurisdiction.
Networking
WireGuard between the dashboard server and the GPU server. TLS termination at Cloudflare for public endpoints. Origin certs from Let’s Encrypt.
Resend for transactional email (account notifications, password resets). Customer alert notifications routed via your configured channels (Telegram, Slack, etc.), not through our email service.
Billing
Stripe for payments. We store the minimum required (Stripe customer ID, subscription state). Card numbers and CVVs are not stored by Glassmkr; they live in Stripe.
No AWS, GCP, or Azure dependency.
Glassmkr does not rely on any major cloud provider for serving customer requests. If AWS has an outage, Glassmkr keeps running.
Self-hosted everything.
Where possible, we run our own infrastructure. The dashboard, the database, the AI model, the WireGuard mesh. Same infrastructure model we expect from our customers.
What we don’t have yet
We’re honest about gaps:
- No ISO 27001 certification. Pursuing this depends on customer demand. Email if your procurement requires it.
- No formal SLA. We run on infrastructure designed for high availability, but we don’t currently offer monetary SLA guarantees.
- No dedicated on-call team. Most operational issues are resolved within hours during European working hours; outages outside those hours may take longer.
If these gaps are blockers for your team, we want to know. Email [email protected].