v0.6.8-remote-access-pass

🚀 Beacon Release — Remote Terminal & Command Rename

This release adds remote terminal to Beacon — open a shell on any device from your browser, through BeaconInfra. No SSH port, no VPN, no port forwarding. Also renames beacon master to beacon start.

---

✨ Highlights

🚇 Tunneling on HA OS

With the beacon home-assistant OS addon you can now enable tunneling (remote access).

🖥️ Remote Terminal and Tunneling

The cloud relays a shell session (PTY) between your browser and the Beacon agent — no SSH port, no VPN needed. Sessions auto-expire after 15 minutes. Set a remote-access passphrase to require a device-verified second factor before any session opens.

How it works:

1. Click "Open Terminal" on a device in the dashboard (Remote Access tab or the Remote Access page)
2. BeaconInfra creates a session and sends a terminal_open piggyback command to the device
3. The Beacon agent picks it up on the next heartbeat, dials back to the cloud via WebSocket, and spawns a local shell
4. Browser ↔ Cloud Hub ↔ Agent PTY — bidirectional relay, binary-safe

How it stays secure — the cloud never sees your passphrase:

The passphrase is never stored. Setup writes only an Argon2id-derived key, its salt, and the cost parameters to ~/.beacon/remote-access.json (mode 0600).
At session time the agent issues a single-use, short-lived nonce. The browser derives the key from your passphrase and returns a proof = HMAC-SHA256(key, nonce ‖ action ‖ session_id). The agent recomputes and compares it in constant time. BeaconInfra only relays this challenge — it never sees the passphrase or any reusable proof, so a fully compromised cloud still cannot open a session.
A successful unlock is in-memory, session-bound, and TTL-limited, and is cleared on restart (fail-closed).
Repeated wrong attempts trigger rate-limiting / backoff to slow brute force.

Security:

• One-time btt_ tokens per session — SHA-256 hashed, only the hash stored server-side
• Sessions auto-expire after 15 minutes (max duration) or 5 minutes idle
• Shell restricted to an allow-list (/bin/bash, /bin/zsh, /bin/sh, /bin/ash, /bin/dash, /usr/bin/bash, /usr/bin/zsh, /usr/bin/fish)
• The agent runs the shell as its own OS user — no privilege escalation
• A stale session reaper runs every 60s to clean up abandoned sessions

⌨️ beacon start (was beacon master)

The command to start the agent is now beacon start. More intuitive, less jargon. beacon master still works as an alias for backward compatibility — existing scripts and systemd units are unaffected.

🚀 Deploy from beaconinfra dashboard

The device detail page now has a prominent "Deploy" button that opens a dialog where you can enter a project name. Triggers the same deploy flow as a new tag detection.

---

🛠️ What's included

• Remote terminal: terminal_open piggyback command, agent-side PTY spawner, cloud WebSocket relay hub
• Browser terminal UI (xterm.js) with resize support and session status feedback
• Terminal session API: POST /api/terminal/sessions, GET .../sessions/:id, POST .../sessions/:id/terminate
• Browser and agent WebSocket endpoints with JWT and btt_ token auth
• Shell allow-list (gosec G702 fix) — rejects arbitrary $SHELL values
• Stale session reaper with ExpireStale storage method
• Structured logging (zerolog) for all terminal events: session create, browser connect, agent connect, relay start, close
• beacon master → beacon start rename across both repos (agent + cloud), master kept as Cobra alias
• Deploy dialog on device detail page with project name input
• Terminal accessible from Remote Access page (device dropdown) and device detail Remote Access tab

---

📋 What's next

• Agent binary rebuild required — devices must run this version for terminal to work. Older agents silently ignore the terminal_open command.
• Terminal sessions are single-user, single-device for now. Multi-tab and session sharing are future work.
• The deploy dialog currently triggers a device-level deploy. Project-targeted deploy via piggyback commands is planned.

Full Changelog: v0.6.3-remote-ssh...v0.6.4-remote-ssh-access

Full Changelog: v0.6.3-remote-ssh...v0.6.5-remote-tty

What's Changed

• Feature: Local Secrets Manager by @Bajusz15 in #159

Full Changelog: 0.6.6-remote-tty-ha-os-tunnel...v0.6.7-remote-access-passphrase

Full Changelog: v0.6.7-remote-access-passphrase...v0.6.8-remote-access-pass

v0.6.7-remote-access-passphrase

🚀 Beacon Release — Remote Terminal & Command Rename

This release adds remote terminal to Beacon — open a shell on any device from your browser, through BeaconInfra. No SSH port, no VPN, no port forwarding. Also renames beacon master to beacon start.

---

✨ Highlights

🚇 Tunneling on HA OS

With the beacon home-assistant OS addon you can now enable tunneling (remote access).

🖥️ Remote Terminal and Tunneling

The cloud relays a shell session (PTY) between your browser and the Beacon agent — no SSH port, no VPN needed. Sessions auto-expire after 15 minutes. Set a remote-access passphrase to require a device-verified second factor before any session opens.

How it works:

1. Click "Open Terminal" on a device in the dashboard (Remote Access tab or the Remote Access page)
2. BeaconInfra creates a session and sends a terminal_open piggyback command to the device
3. The Beacon agent picks it up on the next heartbeat, dials back to the cloud via WebSocket, and spawns a local shell
4. Browser ↔ Cloud Hub ↔ Agent PTY — bidirectional relay, binary-safe

How it stays secure — the cloud never sees your passphrase:

The passphrase is never stored. Setup writes only an Argon2id-derived key, its salt, and the cost parameters to ~/.beacon/remote-access.json (mode 0600).
At session time the agent issues a single-use, short-lived nonce. The browser derives the key from your passphrase and returns a proof = HMAC-SHA256(key, nonce ‖ action ‖ session_id). The agent recomputes and compares it in constant time. BeaconInfra only relays this challenge — it never sees the passphrase or any reusable proof, so a fully compromised cloud still cannot open a session.
A successful unlock is in-memory, session-bound, and TTL-limited, and is cleared on restart (fail-closed).
Repeated wrong attempts trigger rate-limiting / backoff to slow brute force.

Security:

• One-time btt_ tokens per session — SHA-256 hashed, only the hash stored server-side
• Sessions auto-expire after 15 minutes (max duration) or 5 minutes idle
• Shell restricted to an allow-list (/bin/bash, /bin/zsh, /bin/sh, /bin/ash, /bin/dash, /usr/bin/bash, /usr/bin/zsh, /usr/bin/fish)
• The agent runs the shell as its own OS user — no privilege escalation
• A stale session reaper runs every 60s to clean up abandoned sessions

⌨️ beacon start (was beacon master)

The command to start the agent is now beacon start. More intuitive, less jargon. beacon master still works as an alias for backward compatibility — existing scripts and systemd units are unaffected.

🚀 Deploy from beaconinfra dashboard

The device detail page now has a prominent "Deploy" button that opens a dialog where you can enter a project name. Triggers the same deploy flow as a new tag detection.

---

🛠️ What's included

• Remote terminal: terminal_open piggyback command, agent-side PTY spawner, cloud WebSocket relay hub
• Browser terminal UI (xterm.js) with resize support and session status feedback
• Terminal session API: POST /api/terminal/sessions, GET .../sessions/:id, POST .../sessions/:id/terminate
• Browser and agent WebSocket endpoints with JWT and btt_ token auth
• Shell allow-list (gosec G702 fix) — rejects arbitrary $SHELL values
• Stale session reaper with ExpireStale storage method
• Structured logging (zerolog) for all terminal events: session create, browser connect, agent connect, relay start, close
• beacon master → beacon start rename across both repos (agent + cloud), master kept as Cobra alias
• Deploy dialog on device detail page with project name input
• Terminal accessible from Remote Access page (device dropdown) and device detail Remote Access tab

---

📋 What's next

• Agent binary rebuild required — devices must run this version for terminal to work. Older agents silently ignore the terminal_open command.
• Terminal sessions are single-user, single-device for now. Multi-tab and session sharing are future work.
• The deploy dialog currently triggers a device-level deploy. Project-targeted deploy via piggyback commands is planned.

Full Changelog: v0.6.3-remote-ssh...v0.6.4-remote-ssh-access

Full Changelog: v0.6.3-remote-ssh...v0.6.5-remote-tty

What's Changed

• Feature: Local Secrets Manager by @Bajusz15 in #159

Full Changelog: 0.6.6-remote-tty-ha-os-tunnel...v0.6.7-remote-access-passphrase

0.6.6-remote-tty-ha-os-tunnel

🚀 Beacon Release — Remote Terminal & Command Rename

This release adds remote terminal to Beacon — open a shell on any device from your browser, through BeaconInfra. No SSH port, no VPN, no port forwarding. Also renames beacon master to beacon start.

---

✨ Highlights

🚇 Tunneling on HA OS

With the beacon home-assistant OS addon you can now enable tunneling (remote access).

🖥️ Remote Terminal

Open a PTY shell session on your device directly from the BeaconInfra dashboard. Traffic relays through BeaconInfra's WebSocket hub — no SSH daemon, no port 22, no inbound connections needed.

How it works:

1. Click "Open Terminal" on a device in the dashboard (Remote Access tab or the Remote Access page)
2. BeaconInfra creates a session and sends a terminal_open piggyback command to the device
3. The Beacon agent picks it up on the next heartbeat, dials back to the cloud via WebSocket, and spawns a local shell
4. Browser ↔ Cloud Hub ↔ Agent PTY — bidirectional relay, binary-safe

Security:

• One-time btt_ tokens per session — SHA-256 hashed, only the hash stored server-side
• Sessions auto-expire after 15 minutes (max duration) or 5 minutes idle
• Shell restricted to an allow-list (/bin/bash, /bin/zsh, /bin/sh, /bin/ash, /bin/dash, /usr/bin/bash, /usr/bin/zsh, /usr/bin/fish)
• The agent runs the shell as its own OS user — no privilege escalation
• A stale session reaper runs every 60s to clean up abandoned sessions

⌨️ beacon start (was beacon master)

The command to start the agent is now beacon start. More intuitive, less jargon. beacon master still works as an alias for backward compatibility — existing scripts and systemd units are unaffected.

🚀 Deploy from beaconinfra dashboard

The device detail page now has a prominent "Deploy" button that opens a dialog where you can enter a project name. Triggers the same deploy flow as a new tag detection.

---

🛠️ What's included

• Remote terminal: terminal_open piggyback command, agent-side PTY spawner, cloud WebSocket relay hub
• Browser terminal UI (xterm.js) with resize support and session status feedback
• Terminal session API: POST /api/terminal/sessions, GET .../sessions/:id, POST .../sessions/:id/terminate
• Browser and agent WebSocket endpoints with JWT and btt_ token auth
• Shell allow-list (gosec G702 fix) — rejects arbitrary $SHELL values
• Stale session reaper with ExpireStale storage method
• Structured logging (zerolog) for all terminal events: session create, browser connect, agent connect, relay start, close
• beacon master → beacon start rename across both repos (agent + cloud), master kept as Cobra alias
• Deploy dialog on device detail page with project name input
• Terminal accessible from Remote Access page (device dropdown) and device detail Remote Access tab

---

📋 What's next

• Agent binary rebuild required — devices must run this version for terminal to work. Older agents silently ignore the terminal_open command.
• Terminal sessions are single-user, single-device for now. Multi-tab and session sharing are future work.
• The deploy dialog currently triggers a device-level deploy. Project-targeted deploy via piggyback commands is planned.

Full Changelog: v0.6.3-remote-ssh...v0.6.4-remote-ssh-access

Full Changelog: v0.6.3-remote-ssh...v0.6.5-remote-tty

v0.6.5-remote-tty

🚀 Beacon Release — Remote Terminal & Command Rename

This release adds remote terminal to Beacon — open a shell on any device from your browser, through BeaconInfra. No SSH port, no VPN, no port forwarding. Also renames beacon master to beacon start.

---

✨ Highlights

🖥️ Remote Terminal

Open a PTY shell session on your device directly from the BeaconInfra dashboard. Traffic relays through BeaconInfra's WebSocket hub — no SSH daemon, no port 22, no inbound connections needed.

How it works:

1. Click "Open Terminal" on a device in the dashboard (Remote Access tab or the Remote Access page)
2. BeaconInfra creates a session and sends a terminal_open piggyback command to the device
3. The Beacon agent picks it up on the next heartbeat, dials back to the cloud via WebSocket, and spawns a local shell
4. Browser ↔ Cloud Hub ↔ Agent PTY — bidirectional relay, binary-safe

Security:

• One-time btt_ tokens per session — SHA-256 hashed, only the hash stored server-side
• Sessions auto-expire after 15 minutes (max duration) or 5 minutes idle
• Shell restricted to an allow-list (/bin/bash, /bin/zsh, /bin/sh, /bin/ash, /bin/dash, /usr/bin/bash, /usr/bin/zsh, /usr/bin/fish)
• The agent runs the shell as its own OS user — no privilege escalation
• A stale session reaper runs every 60s to clean up abandoned sessions

⌨️ beacon start (was beacon master)

The command to start the agent is now beacon start. More intuitive, less jargon. beacon master still works as an alias for backward compatibility — existing scripts and systemd units are unaffected.

🚀 Deploy from beaconinfra dashboard

The device detail page now has a prominent "Deploy" button that opens a dialog where you can enter a project name. Triggers the same deploy flow as a new tag detection.

---

🛠️ What's included

• Remote terminal: terminal_open piggyback command, agent-side PTY spawner, cloud WebSocket relay hub
• Browser terminal UI (xterm.js) with resize support and session status feedback
• Terminal session API: POST /api/terminal/sessions, GET .../sessions/:id, POST .../sessions/:id/terminate
• Browser and agent WebSocket endpoints with JWT and btt_ token auth
• Shell allow-list (gosec G702 fix) — rejects arbitrary $SHELL values
• Stale session reaper with ExpireStale storage method
• Structured logging (zerolog) for all terminal events: session create, browser connect, agent connect, relay start, close
• beacon master → beacon start rename across both repos (agent + cloud), master kept as Cobra alias
• Deploy dialog on device detail page with project name input
• Terminal accessible from Remote Access page (device dropdown) and device detail Remote Access tab

---

📋 What's next

• Agent binary rebuild required — devices must run this version for terminal to work. Older agents silently ignore the terminal_open command.
• Terminal sessions are single-user, single-device for now. Multi-tab and session sharing are future work.
• The deploy dialog currently triggers a device-level deploy. Project-targeted deploy via piggyback commands is planned.

Full Changelog: v0.6.3-remote-ssh...v0.6.4-remote-ssh-access

Full Changelog: v0.6.3-remote-ssh...v0.6.5-remote-tty

v0.6.3-remote-ssh

🚀 Beacon Release — Remote Terminal & Command Rename

This release adds remote terminal to Beacon — open a shell on any device from your browser, through BeaconInfra. No SSH port, no VPN, no port forwarding. Also renames beacon master to beacon start.

---

✨ Highlights

🖥️ Remote Terminal

Open a PTY shell session on your device directly from the BeaconInfra dashboard. Traffic relays through BeaconInfra's WebSocket hub — no SSH daemon, no port 22, no inbound connections needed.

How it works:

1. Click "Open Terminal" on a device in the dashboard (Remote Access tab or the Remote Access page)
2. BeaconInfra creates a session and sends a terminal_open piggyback command to the device
3. The Beacon agent picks it up on the next heartbeat, dials back to the cloud via WebSocket, and spawns a local shell
4. Browser ↔ Cloud Hub ↔ Agent PTY — bidirectional relay, binary-safe

Security:

• One-time btt_ tokens per session — SHA-256 hashed, only the hash stored server-side
• Sessions auto-expire after 15 minutes (max duration) or 5 minutes idle
• Shell restricted to an allow-list (/bin/bash, /bin/zsh, /bin/sh, /bin/ash, /bin/dash, /usr/bin/bash, /usr/bin/zsh, /usr/bin/fish)
• The agent runs the shell as its own OS user — no privilege escalation
• A stale session reaper runs every 60s to clean up abandoned sessions

⌨️ beacon start (was beacon master)

The command to start the agent is now beacon start. More intuitive, less jargon. beacon master still works as an alias for backward compatibility — existing scripts and systemd units are unaffected.

🚀 Deploy from beaconinfra dashboard

The device detail page now has a prominent "Deploy" button that opens a dialog where you can enter a project name. Triggers the same deploy flow as a new tag detection.

---

🛠️ What's included

• Remote terminal: terminal_open piggyback command, agent-side PTY spawner, cloud WebSocket relay hub
• Browser terminal UI (xterm.js) with resize support and session status feedback
• Terminal session API: POST /api/terminal/sessions, GET .../sessions/:id, POST .../sessions/:id/terminate
• Browser and agent WebSocket endpoints with JWT and btt_ token auth
• Shell allow-list (gosec G702 fix) — rejects arbitrary $SHELL values
• Stale session reaper with ExpireStale storage method
• Structured logging (zerolog) for all terminal events: session create, browser connect, agent connect, relay start, close
• beacon master → beacon start rename across both repos (agent + cloud), master kept as Cobra alias
• Deploy dialog on device detail page with project name input
• Terminal accessible from Remote Access page (device dropdown) and device detail Remote Access tab

---

📋 What's next

• Agent binary rebuild required — devices must run this version for terminal to work. Older agents silently ignore the terminal_open command.
• Terminal sessions are single-user, single-device for now. Multi-tab and session sharing are future work.
• The deploy dialog currently triggers a device-level deploy. Project-targeted deploy via piggyback commands is planned.

v0.6.2-vpn-redeploy

🚀 Beacon Release — Peer-to-Peer WireGuard VPN

This release adds WireGuard VPN to Beacon — a peer-to-peer encrypted tunnel between your devices, with zero cloud involvement in the traffic path.

---

✨ Highlights

🔒 Beacon VPN

Beacon can now set up WireGuard tunnels between your devices. Your traffic flows directly between peers, end-to-end encrypted. BeaconInfra only coordinates key exchange — it never sees your traffic.

Why this exists:

• You're on a cafe, hotel, or airport WiFi and don't trust the network — route your traffic through your own home connection instead
• You're traveling abroad and want to appear as if you're browsing from home
• You want a VPN without paying for a subscription or trusting a third-party provider with your data

No monthly fees. No third-party servers in the middle. Your home internet is your exit node.

🛡️ WireGuard is cryptographically silent

Unlike a typical exposed service, a WireGuard port doesn't respond to anything without valid credentials. Port scanners see it as identical to a closed port. There's no banner, no handshake, no indication anything is listening.

This means forwarding the WireGuard port on your router is dramatically safer than forwarding any application port.

🧰 Simple setup

# Home device (exit node):
sudo setcap cap_net_admin,cap_net_raw+eip $(which beacon)   # one-time
beacon vpn enable
beacon master --foreground

# Laptop (anywhere else):
beacon vpn use my-home-device
beacon master --foreground

# Done — your traffic now routes through home

🏗️ Hardened command dispatch

Remote commands from BeaconInfra (including VPN) now go through defense-in-depth:

• Action allowlist — unknown actions rejected
• Command deduplication — replayed commands skipped
• User-configurable allowlist — restrict what your device accepts remotely via allowed_remote_commands
• Registration rollback — if local VPN setup fails after cloud registration, the stale cloud state is automatically cleaned up

📦 Other improvements

• beacon projects redeploy <name> — pull latest code and re-run the deploy command
• beacon update — self-update with SHA256 verification and proper semver comparison
• Auto-init on beacon master — master creates a default config if none exists
• Linux capabilities instead of sudo — no more running child processes as root
• Removed Kubernetes — observer, templates, and all k8s dependencies dropped (~8MB smaller binary)

---

🛠️ What's included

• WireGuard VPN: beacon vpn enable / use / disable / status
• Curve25519 key exchange, AES-GCM encrypted private key storage
• VPN status in heartbeat and local dashboard
• VPN piggyback commands for remote enable/disable from dashboard
• Cloud-side public IP detection from registration request
• Proper semver version comparison for beacon update
• Cross-filesystem self-update fix
• beacon projects redeploy command
• 40+ new tests across VPN, cloud, dispatcher, and update packages

---

📋 Current scope & what's next

Phase 1 (this release) requires the exit node to have a port-forwarded UDP port (default 51820). This covers most home setups.

Phase 2 (planned) adds STUN-based NAT traversal — neither side needs a port forward. Beacon will not ship a relay. If hole-punching fails (symmetric NAT), you get a clear error rather than your traffic silently routing through someone else's server.

---

❤️ Vision

Beacon started as a deployment and monitoring agent for self-hosted infrastructure.

With VPN, it takes a step toward something broader:

A single agent for running, monitoring, and securely connecting your devices — without handing your traffic to a third party.

Full Changelog: v0.5.2-tunnel-homeassistant...v0.6.1-vpn-wireguard

What's Changed

• ⭐ Structured logger with per-component prefixes by @Bajusz15 in #156
• Beacon VPN (WireGuard) + self-updater + dispatcher hardening by @Bajusz15 in #157

Full Changelog: v0.5.2-tunnel-homeassistant...v0.6.1-vpn-wireguardv0.6.1-vpn-wireguard

Full Changelog: v0.6.1-vpn-wireguard...v0.6.2-vpn-redeploy

v0.6.1-vpn-wireguard

🚀 Beacon Release — Peer-to-Peer WireGuard VPN

This release adds WireGuard VPN to Beacon — a peer-to-peer encrypted tunnel between your devices, with zero cloud involvement in the traffic path.

---

✨ Highlights

🔒 Beacon VPN

Beacon can now set up WireGuard tunnels between your devices. Your traffic flows directly between peers, end-to-end encrypted. BeaconInfra only coordinates key exchange — it never sees your traffic.

Why this exists:

• You're on a cafe, hotel, or airport WiFi and don't trust the network — route your traffic through your own home connection instead
• You're traveling abroad and want to appear as if you're browsing from home
• You want a VPN without paying for a subscription or trusting a third-party provider with your data

No monthly fees. No third-party servers in the middle. Your home internet is your exit node.

🛡️ WireGuard is cryptographically silent

Unlike a typical exposed service, a WireGuard port doesn't respond to anything without valid credentials. Port scanners see it as identical to a closed port. There's no banner, no handshake, no indication anything is listening.

This means forwarding the WireGuard port on your router is dramatically safer than forwarding any application port.

🧰 Simple setup

# Home device (exit node):
sudo setcap cap_net_admin,cap_net_raw+eip $(which beacon)   # one-time
beacon vpn enable
beacon master --foreground

# Laptop (anywhere else):
beacon vpn use my-home-device
beacon master --foreground

# Done — your traffic now routes through home

🏗️ Hardened command dispatch

Remote commands from BeaconInfra (including VPN) now go through defense-in-depth:

• Action allowlist — unknown actions rejected
• Command deduplication — replayed commands skipped
• User-configurable allowlist — restrict what your device accepts remotely via allowed_remote_commands
• Registration rollback — if local VPN setup fails after cloud registration, the stale cloud state is automatically cleaned up

📦 Other improvements

• beacon projects redeploy <name> — pull latest code and re-run the deploy command
• beacon update — self-update with SHA256 verification and proper semver comparison
• Auto-init on beacon master — master creates a default config if none exists
• Linux capabilities instead of sudo — no more running child processes as root
• Removed Kubernetes — observer, templates, and all k8s dependencies dropped (~8MB smaller binary)

---

🛠️ What's included

• WireGuard VPN: beacon vpn enable / use / disable / status
• Curve25519 key exchange, AES-GCM encrypted private key storage
• VPN status in heartbeat and local dashboard
• VPN piggyback commands for remote enable/disable from dashboard
• Cloud-side public IP detection from registration request
• Proper semver version comparison for beacon update
• Cross-filesystem self-update fix
• beacon projects redeploy command
• 40+ new tests across VPN, cloud, dispatcher, and update packages

---

📋 Current scope & what's next

Phase 1 (this release) requires the exit node to have a port-forwarded UDP port (default 51820). This covers most home setups.

Phase 2 (planned) adds STUN-based NAT traversal — neither side needs a port forward. Beacon will not ship a relay. If hole-punching fails (symmetric NAT), you get a clear error rather than your traffic silently routing through someone else's server.

---

❤️ Vision

Beacon started as a deployment and monitoring agent for self-hosted infrastructure.

With VPN, it takes a step toward something broader:

A single agent for running, monitoring, and securely connecting your devices — without handing your traffic to a third party.

Full Changelog: v0.5.2-tunnel-homeassistant...v0.6.1-vpn-wireguard

What's Changed

• ⭐ Structured logger with per-component prefixes by @Bajusz15 in #156
• Beacon VPN (WireGuard) + self-updater + dispatcher hardening by @Bajusz15 in #157

Full Changelog: v0.5.2-tunnel-homeassistant...v0.6.1-vpn-wireguard

v0.5.2-tunnel-homeassistant

🚀 Beacon Release — Tunnels for Home Assistant

This release introduces one of the biggest steps yet for Beacon: tunneling support.

You can now use Beacon to expose local services like Home Assistant securely through a managed tunnel, without manually opening ports or building a separate remote-access setup around your homelab.

---

✨ Highlights

🌐 Tunnel support

Beacon can now run and manage tunnels for local services, making them reachable remotely in a much simpler way.

This is especially useful for self-hosted apps running on:

• Raspberry Pi
• mini PCs
• homelab servers
• home networks behind NAT

Instead of stitching together multiple tools yourself, Beacon can become the place where deployment, monitoring, and remote access meet.

🏠 Home Assistant integration

The main use case for this release is Home Assistant.

You can now tunnel your local Home Assistant instance through Beacon, making it accessible remotely while keeping the setup aligned with Beacon’s local-first, self-hosted approach. You can install Beacon as a Home Assistant app (formerly addon), or if you run Home Assistant in a docker container, just point Beacon to it.

This makes Beacon more than a deploy agent — it starts becoming a real control point for home infrastructure.

🔌 A strong foundation for Beacon Home

This release is also an important step toward a broader vision: using Beacon as the agent that powers services running at home.

Home Assistant is the first natural fit here, but the same tunnel model can later support other local services too.

---

Why this matters

Remote access to self-hosted services is usually annoying:

• router configuration
• port forwarding
• dynamic DNS
• reverse proxies
• certificate setup
• keeping everything stable over time

Beacon now starts to remove that complexity.

With tunnels, the path becomes much simpler:

1. Run your service locally
2. Register or configure the tunnel in Beacon
3. Access it remotely through Beacon’s managed setup

For Home Assistant in particular, this makes remote access much more approachable for users who want control without unnecessary infrastructure overhead.

---

🛠️ What’s included

• support for Beacon-managed tunnels
• Home Assistant as the first clear tunnel use case
• groundwork for exposing more local services through Beacon
• another step toward Beacon as a true self-hosted infrastructure agent for the home

---

❤️ Vision

Beacon started as a deployment and monitoring agent for self-hosted infrastructure.

With this release, it moves further toward something bigger:

A single agent for running, monitoring, and securely accessing services in your home environment.

Home Assistant is just the beginning.

v0.4.1-beacon-master-cloud-login

🚀 Beacon Release

Beacon now ships with a built-in local dashboard, a new beacon status CLI, a Prometheus /metrics endpoint, and a more robust master/child process architecture for managing multiple configured projects. A new cloud login and cloud logout command is introduced for integration with BeaconInfra

---

✨ Highlights

🖥️ Local dashboard at localhost:9100

Beacon now serves a built-in, read-only HTML dashboard with real-time visibility into host health and child agent state.

The dashboard includes:

• CPU
• memory
• disk
• load
• temperature
• recent events
• child/project status

It refreshes automatically, so you can quickly inspect what Beacon is doing locally.

---

💻 New beacon status command

Beacon now includes a terminal-native status view:

beacon status

v.0.4.0-master-children-agents

🚀 Beacon Release

This release brings a big upgrade to Beacon’s local visibility, operability, and resilience.

Beacon now ships with a built-in local dashboard, a new beacon status CLI, a Prometheus /metrics endpoint, and a more robust master/child process architecture for managing multiple configured projects.

---

✨ Highlights

🖥️ Local dashboard at localhost:9100

Beacon now serves a built-in, read-only HTML dashboard with real-time visibility into host health and child agent state.

The dashboard includes:

• CPU
• memory
• disk
• load
• temperature
• recent events
• child/project status

It refreshes automatically, so you can quickly inspect what Beacon is doing locally.

---

💻 New beacon status command

Beacon now includes a terminal-native status view:

beacon status