Axel setup guide / Public index

Public setup notes

How the server-based AI workspace fits together.

This is the public version of the setup guide. It explains the architecture and the reusable operating patterns without publishing the private values needed to access the real environment.

What this page is for

Use it to understand the shape of the workspace: a server that runs developer tools, a public edge layer, focused service pages, and text artifacts that can be passed to LLMs.

ModelOne server workspace, several public documentation surfaces
Public edgeSmall Worker routes for humans and LLMs
Private stateCredentials, host-specific paths, and live service config stay out
SafetyOnly publish reusable concepts and placeholders

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.

The key idea: document the architecture, not the access material. A good public runbook teaches the shape of the system while replacing real domains, users, tokens, IDs, and paths with placeholders.

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.

These public artifacts are not a substitute for private operator notes. They explain patterns and contracts; they do not contain the live values required to operate the environment.

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 overview

Heimdall 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 page

Heimdall 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 version

Theon 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 prompt

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

Reader or LLM The consumer may be a person reading HTML or a model reading text.
Worker route The Worker serves a deliberately small public route.
Safety filter Only publish content that avoids secrets and private identifiers.
Human pages / and /heimdall explain concepts clearly.
Text endpoints /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.

Publish: abstract architecture, route purpose, placeholder-based runbooks, public product names, generic commands, and non-secret examples.
Do not publish: token values, private keys, credential file paths, live hostnames for protected services, tunnel UUIDs, account IDs, personal emails, private IPs, service user names, incident details, or logs with request data.

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.

RouteAudiencePurpose
/HumansPublic index and safety policy.
/heimdallHumansConceptual Heimdall explainer.
/heimdall.txtLLMsPlain-text Heimdall context for piping into a model.
/theon.txtLLMsPlaceholder-based VPS and SSH setup prompt.
Route availability does not imply that private infrastructure details should be added here. Keep sensitive operational notes in private repositories or local runbooks.