localhost, worldwide.

LiveHQ turns an Apple Silicon Mac into a private application platform. Ship web apps and APIs, attach PostgreSQL or SQLite, and publish through managed HTTPS from the Mac app or the signed, agent-ready CLI. Your Mac opens no inbound port and is never published as the app origin in DNS.

Get the Mac betaExplore the platform
URL not yet issued
LiveHQ
Drop a project folder
my-appdeploying…
my-appyour turn — drag the folder
Inspect & buildValidate imageRelease & startHealth & edgeLive

inbound app ports: 0 · app origin in DNS: not published · TLS: managed

deployment paths
12
database modes
3
access modes
5
signed control plane
1

DEPLOY SURFACE

Drop a local folder, select a GitHub project, or hand the signed CLI to a coding agent. Every entry point reaches the same runtime agent, deployment contract, and safety gates.

SIGNED CLI

Built for humans and agents

protocol 12

{

"status": "succeeded",

"phase": "privacy",

"url": "https://app--workspace.livehq.dev"

}

Self-describing failures

Phase, cause, redacted evidence, and the next safe action.

No Docker access

The sandboxed app and CLI never receive the Docker socket.

ONE PIPELINE

Build first. Create resources second.

source sealed once
  1. 01

    Inspect

    Detect the framework and resolve one immutable plan.

  2. 02

    Build

    Seal source once, build Linux ARM64, inspect the image.

  3. 03

    Prepare

    Converge data, secrets, resources, and release work.

  4. 04

    Verify

    Start the candidate and pass its dedicated health gate.

  5. 05

    Publish

    Bind HTTPS and privacy only after the candidate is ready.

The LiveHQ Deploy screen: a project-folder picker, app name field, memory and CPU resource controls, privacy selection from Private to Public, optional database and secrets, and the five-stage pipeline — building image, validating image, starting container, connecting edge, live — beside a live output panel.
THE SAME PIPELINE, IN THE APPprivacy chosen before publish · secrets redacted

FIRST-CLASS BUILDS + STANDARD CONTAINER FALLBACK

Next.js
React
Vite
Vue
Nuxt
SvelteKit
Astro
Node
FastAPI
Rust
Dockerfile
Containerfile

Managed builds use pinned production images. A standard Dockerfile or Containerfile remains the universal escape hatch, with normal image semantics inside bounded runtime isolation.

DATA PLANE

Provision storage with the app, attach it through an exact environment mapping, run an idempotent release task, and publish only after the new candidate is healthy.

DATABASE_URL

Managed PostgreSQL 17

Private connector · per-attachment credentials

DATABASE_PATH

Managed SQLite

Single-app · single-writer lease

EXACT MAPPING

External PostgreSQL

Public TLS providers supported

RELEASE BEFORE TRAFFIC

01 database ready

02 release: ["node", "scripts/migrate.mjs"]

03 candidate started

04 GET /healthz → 204

05 previous route → candidate

Database credentials are runtime-only. They do not enter image builds, Docker metadata, logs, or command arguments.

DATABASE STUDIO

Operate the data without leaving LiveHQ.

Browse data
Run SQL
Inspect schema
Explore ER
Import
Export

Add encrypted local or R2 backups when the workload needs them, then restore into a new resource instead of gambling on the original.

Database Studio in LiveHQ: an SQLite database stored on the Mac with Data, SQL, and Schema tabs, a checklist_items table showing rows, an inspector panel with schema details, and a safety note explaining that writes briefly pause the connected app while changes are validated.
DATABASE STUDIO, IN THE APPbrowse · query · import · export — on your hardware

EDGE ACCESS

LiveHQ evaluates access before a request reaches your Mac. Start private, invite exactly who needs it, or publish for everyone when the product is ready.

PRIVACY POLICY

Choose the audience, not another proxy.

edge enforced

Private

Only you

People & teams

Named members and guests

Password

Anyone with the generated password

Workspace

Every active workspace member

Public

Anyone with the link

DOMAINS

Managed HTTPS, including your name.

product.example.com

CNAME → proxy-fallback.livehq.dev

active
verifying DNS… DNS verified issuing TLS… TLS active binding route… Route active

Signed app identity

Protected apps can receive a signed identity for the authenticated visitor, with access history and immediate revocation through the access epoch.

The Privacy & access screen for a running app: password-protected general access, an Add people or teams control, the list of people with access, and app-password rotation with a Generate new password button.
PRIVACY & ACCESS, IN THE APProtate the password any time · access history built in

People and teams: invitations, guests, team membership, Shared with me, and an Access Portal are built into the workspace model.

Backend APIs: public routes work with remote services. For machine-to-machine protection, use API keys, JWT, or another protocol inside your application.

OPERATIONS

Live deployment output, semantic CLI errors, health probes, container state, recent application logs, resource metrics, and recovery state all describe the same operation.

Deployment output

build · release · startup · health · privacy

secrets redacted · 64 KiB bound
  1. Building imagequeued
  2. Validating imagequeued
  3. Running releasequeued
  4. Starting candidatequeued
  5. Checking healthqueued

An app Overview screen in LiveHQ: Running status with its public URL, CPU under one percent, memory at seven percent, the source folder ready for redeploy, and runtime evidence — local binding, deployed-from, version, image version, digest, network and block I/O, and process count.
RUNTIME EVIDENCE, IN THE APPevery number on this screen is live

Safe updates

A failed redeploy leaves the previous healthy release routed.

Exact recovery

Interrupted work resumes the same intent instead of reconstructing resources.

At-most-once release

Durable release tasks do not run twice after an interruption.

Bounded evidence

Build, startup, container, and health evidence is redacted and capped.

SERVER MODE

Before a Mac serves production traffic, LiveHQ checks that it actually can. Desktop-class hardware on power, disk headroom, FileVault on, signed runtime images, backups that restore, updates in a safe state. Laptops stay preview machines.

Animated readiness panel: seven production gates check one by one and turn green — desktop-class Mac, disk headroom, FileVault, runtime image signature, backups, updates, edge reachability — then a PRODUCTION READY chip appears. Beside it, a MacBook Air on battery stays amber: preview machine, production needs always-on.

livehq — productionchecking readiness…
  • Desktop-class MacMac mini M2 · on power
  • Disk headroom412 GB free
  • FileVaultenabled
  • Runtime imagesignature verified
  • Backupsencrypted · last restore test: passed
  • Updatessafe state · no pending reboot
  • Edge reachabilityoriginlink: connected
also on this account
MacBook Air · on battery

preview machine — production needs always-on

If the Mac sleeps, the apps sleep. Production Macs don't sleep.

Signed VM images

unverified images refuse to boot

Encrypted backups, restore-tested

last restore test: passed

Hardware-backed identity — P-256 in the Secure Enclave

the key never leaves the chip

ORIGINLINK EDGE

Visitors meet the public edge first—TLS terminated, access checked, and request envelopes signed. Authorized traffic rides the outbound OriginLink connection. Your Mac opens no inbound app port and is not published as the application origin in DNS.

Live diagram: a Mac mini inside a home boundary opens a single outbound OriginLink tunnel to a shield of edge nodes. Visitors reach the edge and only filtered traffic travels down the tunnel. Attacks shatter on the edge membrane while a packet log prints matching DROP lines. The origin remains behind the outbound connection rather than being published as the application endpoint.

drag the diagram
drops: 1,046ports: 0

The internet sees the edge. It never sees you.

Your house stays a house. The internet meets you at the edge.

No open ports

inbound: 0 listeners

No forwarded router rules

router table: untouched

DDoS absorbed at the edge

public network absorbs floods

read the security model — ten laws, zero adjectives →

TRUST BOUNDARY

Public HTTPS terminates at the edge. An outbound OriginLink connection carries authorized traffic to the signed runtime agent, which alone can operate Docker Desktop and Keychain state.

01

Client

HTTPS request

02

Privacy edge

TLS + access

03

OriginLink

Outbound tunnel

04

Runtime agent

Signed broker

05

App + data

Docker Desktop

No inbound port

The Mac initiates the tunnel. No router forwarding rule is required.

No Docker socket in the UI

The sandboxed Mac app and CLI communicate through signed typed XPC.

Bounded execution

Resources, PIDs, logs, networks, capabilities, and host access are constrained.

Managed runtimes add non-root, read-only isolation. Standard container projects keep their declared user and filesystem semantics, while privileged mode, host mounts, Docker socket access, devices, and unsafe capabilities remain unavailable.

Read the security model

BETA REQUIREMENTS

Real infrastructure has a real operating envelope.

LiveHQ is not serverless abstraction. Your Mac is the origin, its capacity is the capacity you own, and Docker Desktop is the runtime underneath it.

macOS 15+
Current beta minimum
Apple Silicon
ARM64 builds and runtime
Docker Desktop
The only supported local runtime
Always reachable
Apps are online while the Mac and tunnel are online

Why LiveHQ exists

Personal software is having its moment.

Everyone can build an app now. Almost no one owns where it runs.

The cloud was never a place.

It was always someone else's computer.

Yours is better.

QUESTIONS

Does my home IP get exposed?

Your Mac opens no inbound port, and its address is not published as the application origin in DNS. It establishes an outbound OriginLink connection; visitors meet the public edge first, and authorized traffic is carried back over that connection.

inbound app ports: 0 · app origin in DNS: not published

What happens when my Mac sleeps or goes offline?

Your applications become unavailable until the Mac, Docker Desktop, and the outbound edge connection are running again. LiveHQ keeps durable runtime intent and recovers current applications after interruption instead of treating each restart as a new deployment.

durable intent · interruption recovery

Do you see my code or my data?

Builds, application containers, managed PostgreSQL, SQLite, and local backup data run on your Mac. LiveHQ's public services coordinate accounts, routes, access, and the encrypted edge connection; application secrets are delivered at runtime and excluded from image builds.

compute + primary data: your Mac

What can a malicious visitor actually reach?

Managed applications run non-root, read-only, capability-free, resource-capped, and isolated from the host and sibling apps. Standard custom containers keep their declared image semantics, but privileged mode, host mounts, Docker socket access, devices, and added capabilities remain unavailable.

host boundary: signed runtime agent

Do I need a static IP, DNS setup, or router changes?

No. The connection is outbound, so your router stays untouched and a changing ISP address does not require dynamic DNS. Each published app receives a managed livehq.dev URL; custom domains connect through the exact CNAME shown in LiveHQ, with ownership verification and TLS status visible in the app.

port forwarding: none · dyndns: not needed

What can I deploy?

LiveHQ has managed paths for Next.js, React, Vite, Vue, Nuxt, SvelteKit, Astro, generic Node, FastAPI/Python, and Rust. A standard Dockerfile or Containerfile is the universal fallback for other web frameworks and services.

managed builds + standard container fallback

Can an application use a database and run migrations?

Yes. A deployment can create or attach managed PostgreSQL 17 or SQLite, or connect to an external TLS PostgreSQL service. Release commands run before the candidate becomes active, and a dedicated health gate must pass before LiveHQ changes the public route.

database → release → health → publish

Can a coding agent deploy through LiveHQ?

Yes. The signed livehq CLI uses the same runtime agent as the Mac app and returns stable JSON with the failed phase, semantic error, redacted evidence, and next safe action. The agent never needs the Docker socket or permission to reconstruct infrastructure.

livehq.cli.result.v2 · typed actions

Can another backend call an API hosted on LiveHQ?

Public applications work like ordinary HTTPS services. For protected machine-to-machine traffic, use an application-level API key or signed token today; browser-oriented private and password access flows are designed for people and are not a substitute for service credentials.

public HTTPS · app-level M2M credentials

What does the Mac need?

The current beta supports Apple Silicon Macs on macOS 15 or later and uses Docker Desktop as the local runtime. The Mac must remain awake and connected whenever its applications need to be reachable.

macOS 15+ · Apple Silicon · Docker Desktop

The public release URL will be added here.

macOS 15+ · Apple Silicon · Developer ID signed · notarized

or read the security model first →