← All work

Product engineering

Whamlink

A publishing system for the things people and AI tools create.

Built and operated by Outermost

Product development · Publishing infrastructure · AI integrations

Visit Whamlink

Scroll across to explore the interface.

View full-size screenshot →
Whamlink dashboard showing sample published reports, dashboards, and documents with their sharing settings.
Whamlink dashboard, shown with sample artifacts and account data.

The product

Publishing with a place to manage it.

Reports, dashboards, documents, and interactive pages get a stable link, content updates, and access controls. Publishing works through a web dashboard, a command-line tool, and integrations for AI assistants.

The dashboard brings published artifacts, access settings, and link management together. It gives the output of a script or AI conversation a place to live beyond that session.

Updating a published artifact

Replacing an artifact creates a new revision behind its existing link. Viewers receive the current content through the content-serving layer.

  1. PublisherSubmit an update
  2. ApplicationCheck access + save revision
  3. StorageStore versioned content
  4. ViewerOpen the same link

System architecture

From artifact to a working link.

Selected publishing and delivery paths
Whamlink publishing and delivery architectureDashboard, CLI and MCP publish through the Hono application on Railway. PostgreSQL stores accounts and link metadata. Cloudflare R2 stores artifact bytes. Browser viewers load a separate Cloudflare Worker that verifies restricted-content tokens locally and retrieves content from R2. Resend sends access emails. Publish / update Store revisions Link records Link access Load content Read bytes Publishing toolsReact dashboardCLI + MCP integrationsOne publishing API Whamlink APIHono / Node.jsPublishing, versions & accessAccounts and sharing controlsHosted on Railway PostgreSQLAccounts, links & permissionsHosted on Railway Cloudflare R2Versioned artifact storage Browser viewerOpen a published link Cloudflare WorkerSeparate content originToken checks + sandbox CSPArtifact delivery from R2 SUPPORTING SERVICEResend · Sign-in, verification and shared-link access emails

Publish through the dashboard, CLI, or MCP. The application manages the link; the content-serving layer delivers the saved artifact.

Providers and responsibilities
  1. Publish and manage

    The React dashboard, CLI, and MCP integrations use the same publishing API.

  2. Whamlink API · Railway

    A Hono application manages accounts, links, revisions, and access rules. PostgreSQL stores their records.

  3. Cloudflare R2

    The application stores replacement content under a new object key. The sharing link stays the same.

  4. Cloudflare Worker

    The browser loads artifacts from a separate origin. The Worker verifies content tokens for restricted links and retrieves bytes from R2.

  5. Resend

    Email supports sign-in, verification, and access to restricted shared links.

The Railway application manages publishing and access. PostgreSQL holds link metadata; Cloudflare R2 holds artifact bytes. Published content is delivered through a separate Cloudflare Worker and content origin.View the full diagram →

Engineering decisions

A link people can keep using.

Separate content from the app.

Published artifacts are served from a separate origin with a sandbox policy. The viewer and content-serving path enforce access rules, keeping artifact execution separate from the application session.

Keep the link. Version the content.

A stable sharing URL points to the current artifact revision. Versioned object keys in R2 let the content change without reusing cached bytes from an earlier upload.

Make publishing a shared capability.

The dashboard, CLI, API, and MCP integration connect to the same publishing system. AI tools can publish and update artifacts while people manage their links and sharing settings in the web interface.

Contact

What would you like to build or improve?

hello@outermost.us