Trust at Glassmkr.

The code 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, and the code it reports to. Both are open source.

Crucible, the agent, 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 dashboard is AGPL-3.0-only.

Source at github.com/glassmkr/crucible. The server side is not a black box either: the ingest API, the alert evaluator, every rule and its thresholds, the storage schema and the retention logic are all in the open. "Read the source" now covers both ends of the wire.

Self-host it, and none of your data reaches us.

The whole stack runs on your own hardware with one docker compose file. No metric, no alert state and no diagnostic excerpt reaches Glassmkr: the agent reports to a dashboard you operate. Self-host in 10 minutes.

This page used to say "nothing leaves your network at all". That is not true, so here is the exception list. Three things reach the internet by default and none of them carry your data: the dashboard reads the public endoflife.date dataset to judge OS support windows, it asks the npm registry which agent version is current, and the agent's security-patch check shells out to your package manager, so apt or dnf talks to whatever mirrors that host already uses. All three are in the source. An air-gapped deployment loses those three features and nothing else.

The install script is about 130 lines of bash.

Read it at install.sh before piping it to bash. It installs Node from NodeSource if the host does not have it, installs @glassmkr/crucible from npm, installs smartmontools and (best effort) ipmitool so disk and chassis checks work, sets up a systemd service, and hands off to init to register the node. That is the whole script; read it and check.

Installation needs root once. The daemon that keeps running does not.

Installing is a root step, as any package install is: it adds a system user, writes a systemd unit, installs packages. After that Crucible runs as the unprivileged glassmkr user. It cannot read files outside its operational scope, cannot execute commands as other users, and writes one log file and one state file in its own directory.

Some hardware reads do need privilege, and that is worth stating plainly rather than hiding behind "never root". Reading SMART attributes or BMC sensors is privileged on most systems. Those calls go through a single root-owned wrapper with a fixed argument list and an allowlisted set of actions, so the escalation boundary is one short file you can read rather than a claim you have to accept. The residual risk is worth naming too: anyone who can edit that wrapper, or who can already run as the glassmkr user and finds a flaw in how it handles arguments, gains whatever the allowlist permits. What limits that is the allowlist being short, fixed at install time, and reviewable in the agent repository.

Observed, not just asserted.

Everything above is a claim about source code, and source claims are the easy kind to make. So the destinations were also measured on a running host rather than read out of the repository: an iptables rule matching on --uid-owner glassmkr logged every outbound connection the agent's own user opened, across a full collection cycle including a security-patch check. What appeared was the configured dashboard and the host's existing package mirrors, and nothing else. The method is three lines, and you can run it on any host you trust less than you would like to:

sudo iptables -A OUTPUT -m owner --uid-owner glassmkr -j LOG --log-prefix "glassmkr-egress: "
sudo systemctl restart glassmkr-crucible
sudo journalctl -kf | grep glassmkr-egress

That measures the agent's own user. It does not measure the package manager, which runs as root when the patch check invokes it, and that is exactly why the mirrors are named separately above rather than folded into this result.

HTTPS only.

Crucible reports to the dashboard address you configured, over HTTPS. There is no analytics provider and no usage telemetry. Its own outbound connections go to that dashboard, to Slack or Telegram if you enable them in the agent's config, and to your package manager's existing mirrors when the security-patch check runs. Email is handed to the local mail system.

What leaves your server, and what does not.

Crucible ships metrics and alert state, plus small bounded diagnostic excerpts attached to a firing alert (for example the last journal lines of a failed service, or matched kernel dmesg events) so the alert is actionable without SSHing to the box. It does not stream logs in bulk, does not ship command output, and does not read or ship arbitrary file contents. A failed service's journal lines can contain sensitive strings, so treat that bounded evidence as in scope for your own secret hygiene. See the Data handling section for the full list.

Release integrity.

Every Crucible release from 1.0.1 onward carries a build-provenance attestation for each single-file binary, tying its exact bytes to the workflow, repository and commit that produced it. Releases also publish a SHA256SUMS file, and the npm package carries the provenance described below. There is no GPG key, deliberately. Attestation binds provenance to the build workflow itself, so there is no private key for one maintainer to hold, rotate, or lose. (An earlier version of this page argued that losing a signing key would invalidate past signatures. That was wrong: verification uses the public key, which survives. Losing the private key stops future signing, nothing more.)

You can verify a download without a GitHub account. Every command below works logged out, which we checked on a clean machine rather than assuming:

curl -fsSLO https://github.com/glassmkr/crucible/releases/download/v1.0.1/glassmkr-crucible-linux-x64
  curl -fsSLO https://github.com/glassmkr/crucible/releases/download/v1.0.1/SHA256SUMS
  sha256sum --ignore-missing -c SHA256SUMS

  D=$(sha256sum glassmkr-crucible-linux-x64 | cut -d' ' -f1)
  curl -fsSL "https://api.github.com/repos/glassmkr/crucible/attestations/sha256:$D" \
    | jq -c '.attestations[0].bundle' > bundle.jsonl

  gh attestation verify glassmkr-crucible-linux-x64 --repo glassmkr/crucible \
    --bundle bundle.jsonl

A successful verification is silent and exits 0. To see what was actually proved, add --format json and read buildSignerURI: it names the workflow and the tag that built those bytes. Note that gh attestation verify without --bundle asks GitHub for the attestation directly and requires you to be logged in, even for a public repository. The bundle route above avoids that, which is why it is the one we document.

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).
• Bounded diagnostic excerpts attached to a firing alert: the last few journal lines of a failed systemd unit, and matched kernel dmesg events. These can contain application strings, so they are in scope for your secret-hygiene review.
• No bulk log streaming, no raw command output, no arbitrary file reads.

Data storage

PostgreSQL + ClickHouse on a server in Amsterdam, Netherlands (verifiable in the RIR record; see infrastructure provenance below). Daily encrypted backups stored on a second server in the same datacenter.

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

This section applies to the hosted instance at app.glassmkr.com. A self-hosted deployment is yours alone: we have no access to it, and nothing about your servers reaches us.

Glassmkr is operated by one person, who has the technical access required to run the hosted 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

• Operator 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 run a monitoring service. There is no advertising and no data business behind it.

If your security requirements rule out any hosted service, you don’t have to ask for an exception: the whole stack is open source and self-hostable, and a self-hosted deployment is one we cannot access at all.

Security disclosure

If you’ve found a security issue in Crucible, the dashboard, or any Glassmkr infrastructure:

Email

[email protected]. If you would rather not send details in plaintext, use the GitHub private vulnerability report below.

GitHub private vulnerability reporting

The agent repository has GitHub’s private vulnerability reporting enabled. SECURITY.md describes both routes: the private report form on GitHub and [email protected].

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.

You do not have to take the location on trust. The dashboard answers on 89.187.174.239 and the GPU host on 185.229.190.89; both are RIPE allocations with country code NL and the network name CDN77-AMS. One command, from your machine, no account:

whois 89.187.174.239 | grep -Ei '^(country|netname)'

One nuance that the phrase "EU jurisdiction" was hiding, so it is stated here instead: the servers are in the Netherlands, and the network operator's legal entity is DataCamp Limited, registered in London. The data controller is in the Czech Republic and is named on the privacy policy. Those are three different places and a single phrase could not carry all three honestly.

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): analysis runs on the host named above, on the same Amsterdam network as the dashboard, over WireGuard.

Networking

WireGuard between the dashboard server and the GPU server. TLS termination at Cloudflare for public endpoints. Origin certs from Let’s Encrypt.

Email

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].