What This Is
The workspace pattern is simple: keep the powerful tools on an always-on server, expose only small documented surfaces, and make each surface explicit about its audience. Humans get explanatory pages. LLMs get plain text context. Automation gets narrow endpoints only when there is a real need.
The private environment may include terminals, background services, tunnels, model shims, and deployment tooling. This public page does not publish the concrete values that would let someone operate or target those systems. It explains the pattern so the setup is understandable and repeatable.
Workspace Layers
The setup is easier to reason about as layers. Each layer has a narrow job, and the public docs should describe that job without leaking private state.
Server workspace
An always-on Linux server runs terminal sessions, developer CLIs, background helpers, and project checkouts. It is the place where long-running coding and operations work can continue after a laptop disconnects.
Edge and access layer
Public-facing routes should be small and intentional. DNS, tunnels, access controls, and Workers can expose useful entry points without exposing the server itself or its private service ports.
AI tooling layer
Claude Code, MCP tools, and local shims can operate from the server. The public docs describe what each tool does, not the credentials or personal account state that make it work.
Documentation layer
Human pages explain concepts and decisions. Text endpoints provide compact, structured context that can be piped into another LLM without page chrome or styling.
How To Use It
The site has two modes. Read the HTML pages when you need the concept. Fetch the text endpoints when you want another model to use the material as input.
Understand the architecture
Start on this page. It explains the workspace pattern, what is public, what stays private, and why the documentation is split by audience.
Explain Heimdall to a human
Use /heimdall. It explains Heimdall as a local API shim and router, with chat and embeddings as separate backend routes.
Feed Heimdall context to an LLM
Use curl -fsS https://axel-setup.axhl.io/heimdall.txt. The output is plain text, structured for copy/paste or shell piping.
Generate a VPS setup plan
Use curl -fsS https://axel-setup.axhl.io/theon.txt. The prompt forces the receiving model to ask for placeholders instead of inventing domains, users, IPs, or tunnel names.
Published Resources
Each published resource has a specific audience. Keeping these artifacts separate makes the content clearer and reduces the temptation to publish private operational detail in a general page.
Public overview
The root page explains the reusable architecture pattern, common workflows, and the publish-safety policy. It is intentionally not an operator console.
Open overviewHeimdall explainer
A focused human page explaining Heimdall as one authenticated local API entry point for multiple AI backends. Use it when someone needs the mental model.
Open Heimdall pageHeimdall LLM context
A curated plain-text fact sheet designed to be piped into another model without page chrome or CSS. Use it for analysis, summaries, or generated client docs.
Open text versionTheon setup prompt
A placeholder-driven prompt for generating VPS and SSH setup instructions without inventing private values. Use it when planning a new server setup.
Open Theon promptDocumentation Map
This map shows the public documentation surface, not private infrastructure. It is safe to publish because it describes route intent rather than credentials or internal access details.
/ and /heimdall explain concepts clearly.
/heimdall.txt and /theon.txt are structured for LLM input.
Safe Publishing
Safe public setup content explains architecture and procedure without exposing the private data needed to operate the real environment. When the content needs a value that differs per operator or account, use a placeholder and make the execution-time prompt ask for it.
Recommended redaction pattern
<DOMAIN>
<SSH_HOST>
<VPS_USER>
<SERVER_NAME>
<TUNNEL_NAME>
<TOKEN_VALUE>
When a runbook needs a real value, it should ask the operator for that value at execution time and avoid storing it in public source.
Public examples should stay generic
A public command can show ssh <VPS_USER>@<SSH_HOST>. It should not show the real username, hostname, tunnel ID, token environment file, or credential path. This keeps the guide useful while preserving the boundary between documentation and operations.
Non-goals
- This site is not a status dashboard.
- This site is not a secret store or credential inventory.
- This site is not the place for live hostnames, private service routes, incident notes, or account-specific setup records.
- This site should not contain one-off debugging transcripts unless they have been fully generalized and redacted.
Routes
These are the intended public routes on this Worker.
| Route | Audience | Purpose |
|---|---|---|
/ | Humans | Public index and safety policy. |
/heimdall | Humans | Conceptual Heimdall explainer. |
/heimdall.txt | LLMs | Plain-text Heimdall context for piping into a model. |
/theon.txt | LLMs | Placeholder-based VPS and SSH setup prompt. |