When Apple discontinued macOS Server.app, Mac users lost the simple, point-and-click way to run websites and services. FrontierStack brings that back and goes much further: it installs, controls, secures and monitors Apache, PHP, MySQL, PostgreSQL, Nginx and more than a thousand other services — on the Mac in front of you and on every server you link to it — and it puts a tool-using AI administrator at the helm.

This manual is the complete reference for the desktop app. A companion Mobile Manual covers the iPhone and iPad app. Read this first chapter end to end; after that, dip into whichever part you need.

1.1What FrontierStack is

FrontierStack is a native macOS application — not a web panel, not a container you have to babysit. It manages real services on real machines using the tools they already ship with: Homebrew formulae, launchd and systemd units, Apache and Nginx config, certificates, firewalls and SSH. It is three things at once:

• A control panel. Install, start, stop and configure services with validation, live status and one-click fixes — the macOS Server replacement, modernised.
• A monitoring and alerting system. A continuous health sweep watches services, sites, certificates, disks and your whole fleet, and turns the first sign of trouble into a message on the channels you choose.
• An AI administrator. A guard-railed, tool-using assistant with a live, accurate picture of your setup. It can diagnose what is broken, propose a fix you approve, run it locally or across your fleet, and reshape the app to exactly what you run.

1.2An AI-first design

Most apps bolt a chat box onto the side. FrontierStack is built the other way around: the AI is a first-class operator of the same controls you use. Because it acts only through a fixed set of audited tools — read a log, run a diagnostic, restart a service, issue a certificate, write a file — everything it does is something you could do by hand, and everything that changes the system is shown to you for approval first.

Three principles make this safe enough to trust with production servers:

• Read-only by default. Out of the box the assistant can look but not touch. Changes and scripts are unlocked by explicit toggles, and every mutating action shows an approval card before it runs.
• Your secrets never reach the model. Passwords and API tokens live in a local .env vault. Scripts reference them by name; the app injects the real value at run time, locally or over SSH. The cloud model sees the name, never the value. Logs and files are secret-redacted before they are sent.
• You bring your own AI. Point it at a cloud model or a local one (Ollama, LM Studio). If you drive it from your own subscription tool over MCP — Claude Code, Cursor — there is no metered per-token bill at all.

1.3Who it is for

FrontierStack suits anyone running — or wanting to run — servers on a Mac:

• Developers who want a clean local stack instead of MAMP or XAMPP.
• Small businesses self-hosting POS, CRM, e-commerce, mail and helpdesk on a Mac mini.
• Admins keeping a vintage Xserve or Mac mini on macOS Server useful by managing it remotely.
• Anyone moving from metered SaaS to self-hosted, or running a fleet of Macs, Linux boxes, BSD servers and Raspberry Pis from one window.

1.4Key concepts and vocabulary

A handful of terms recur throughout this manual. Meet them once here.

1.5How this manual is organised

The manual follows the shape of the work:

• Part I — Getting Started: install, first run, and a tour of the interface.
• Part II — Running Services: the web stack, databases, the full catalog, and sites & domains.
• Part III — Fleet, Network & Security: linking servers, networking and the perimeter, hardening, and monitoring & alerts.
• Part IV — Automation & AI: scripts and schedules, the AI Administrator in full, MCP, and the AI stack.
• Part V — Business & Reference: vertical solutions, settings, shortcuts, licensing and troubleshooting.

If you are brand new, continue to Chapter 2, Installation & First Run. If you just want to understand the AI, jump ahead to Chapter 13 — but the safety model there assumes the concepts above.

FrontierStack installs like any other Mac app — drag it to /Applications and open it. What happens next is up to you: it can run entirely with the per-action password prompts macOS already gives you, or you can grant it a small set of permissions once and never be asked again. This chapter walks the whole first run, then shows how to migrate an existing local stack so you keep your sites and databases.

2.1System requirements

FrontierStack is a native, signed macOS application. You need:

Nothing in this list is unusual; if your Mac is recent enough to run a current macOS, it can run FrontierStack.

2.2Downloading and first launch

Download the app, move FrontierStack.app into your /Applications folder, and double-click it. Because the app is signed by Enfour, Inc. (Apple Developer team 6Y87KNMALP) and notarised, macOS opens it without the unidentified-developer warning.

1. Open FrontierStack. The main window appears with the service sidebar on the left and a health overview in the centre — the layout you met in Chapter 1.
2. If Homebrew isn't present yet, panes that need it will say so and offer to install it. You can do that now or later.
3. FrontierStack enforces a single running instance. If a copy is already open and you launch it again, the existing window is simply brought to the front rather than a second copy starting. This keeps two windows from fighting over the same services and config files.

The first launch makes no changes to your system. The app reads what is installed and shows you the state of things; nothing is started, stopped or reconfigured until you ask.

2.3The Setup Assistant

The first time you open FrontierStack it offers a short Setup Assistant rather than dropping you into a sidebar of several hundred services. It is seven pages, it asks about you rather than about configuration, and nothing it asks is permanent — every answer only decides what the app shows and suggests first. You can leave at any point and reopen it from Add Server or Device ▸ Setup Assistant.

The last page is about licensing, and it is honest rather than a sales gate. FrontierStack works unlicensed — monitor this Mac, connect servers, use the AI Administrator, read every diagnostic. One capability in the plan you just built is licensed: running a migration. Moving a stack copies databases, sites and configuration onto a target and changes what runs there, so it needs a licence. Without one FrontierStack still detects the source, lists the sites and databases it found, and shows exactly what a migration would move — and the AI Administrator will still write you the full plan. Only carrying the move out is gated, and the Migration pane says so on the button rather than failing silently.

Containers, backup destinations and monitoring are deliberately not installed from the Stack page. They need decisions the assistant should not make on your behalf, so they go into the plan instead.

2.4The privileged helper — and the permissions macOS asks for

Starting and stopping services and editing system configuration (Apache, Nginx, MySQL, DNS, the firewall) are privileged operations. Out of the box, FrontierStack performs each one through the standard macOS authorisation prompt: you type your password every time. That is safe but quickly becomes tedious.

The optional helper removes that friction. It is a small privileged tool — an SMAppService daemon — that the app registers with macOS so it can carry out admin actions without re-entering your password each time. You install it deliberately: use the Install affordance at the foot of the sidebar, or accept the prompt when an action first needs it.

1. Click Install on the helper row at the bottom of the sidebar.
2. macOS shows its Login Items & Extensions approval (or asks you to enable the background item in System Settings ▸ General ▸ Login Items). Approve it — this is macOS asking whether to let the daemon run, not the app overriding anything.
3. The sidebar row flips to show the helper registered and running. From now on, service start/stop and config edits proceed without the per-action password prompt.

You can remove the helper at any time; FrontierStack then falls back to per-action admin prompts. Both modes work — the helper is purely a convenience.

2.5Installing Homebrew

Most of the catalog — web servers, databases, caches, mail, dozens of CLI tools — is installed as Homebrew formulae. Homebrew is the package manager FrontierStack uses to fetch and update those services, so if it isn't already on your Mac you'll want it early.

Open the Homebrew pane from the sidebar. If Homebrew is missing, the pane says "Homebrew isn't installed. It's the package manager this app uses to install services," with a Get Homebrew… button. Installation runs in the app's in-app console: it executes the official Homebrew installer and, at the point the installer needs administrator rights, you type your own password into the console. FrontierStack never captures or stores it — the prompt is Homebrew's own.

Once Homebrew is present, the pane becomes a full package manager: a searchable table of installed formulae and casks with their versions, an Install formula or cask field, an Update All button that shows the outstanding count, and per-row Update / Uninstall actions. The AI Administrator can drive the same flow with its install_homebrew and install_package tools, again through the in-app console where you enter your password.

2.6The Command-Line PATH pane

FrontierStack detects installed tools by resolving them the way your shell does. Occasionally a tool you've installed (via pip, pipx, a virtualenv, or a non-standard prefix) isn't on the PATH the app sees, so it reports the tool as missing. The Command-Line PATH pane fixes that.

• Pick your shell profile (for example ~/.zprofile). Directories you add are written to a clearly marked managed block in that file and prepended to your PATH — open a new terminal to pick up the change.
• Directories to add lets you add a path by typing it or with Choose…; the top entry is searched first. Current PATH (effective) shows your login shell's PATH, tagging entries the app manages.
• PATH Doctor diagnoses why a tool isn't detected: enter a command (e.g. mlx_lm.server, gcloud) and it reports whether the app finds it, whether only your shell finds it, or whether it isn't installed at all — with a one-click Add to managed PATH for any directory the app is missing.

2.7The Install Wizard

If you're starting from scratch, the Install Wizard (in the sidebar) is the fastest way to a working stack. Pick a target use-case — WordPress/PHP, Full-Stack JS, Python/Django, Rails, static site, database, or reverse proxy — and the wizard pre-selects the recommended components (web server, database, cache) for that goal. Adjust the selection to taste, then it installs everything through Homebrew.

The same pane shows the status of the native Apache + MySQL + PHP stack at a glance, and detects all-in-one bundles already on your Mac — XAMPP, MAMP, AMPPS, Local. If it finds one, it routes you to Migrate Setups rather than installing a parallel stack, so you don't end up running two of everything.

2.8Migrating an existing stack

If you already run sites locally under MAMP, XAMPP or Apple's Server.app, you don't have to rebuild them. The Migrate Setups pane detects those stacks and brings their pieces into FrontierStack's native Homebrew stack: web files, MySQL databases, PHP settings, and the Apache vhosts that define each site.

1. Open Migrate Setups. It scans for installed sources — MAMP / MAMP Pro, XAMPP and Apple Server — and reports what it found: the sites, the database, and whether PHP was detected. (The AI Administrator's detect_migration_sources tool runs the same read-only scan.)
2. Review the Sites to import list. Each candidate shows its server name and listening port; anything that can't be brought across cleanly appears under Skipped with the reason.
3. For settings, the Import All Settings action copies the source's php.ini, my.cnf and nginx.conf over the matching Homebrew config. A .pre-mamp.bak backup of each file is kept so you can compare or revert.
4. Choose Import Selected to run the migration. Live progress is shown in the pane as it installs the needed Homebrew services, copies web files, migrates the MySQL databases and imports the vhosts.
5. Review afterwards. Source configs often reference the old tool's paths and ports (for example MAMP's extension_dir, datadir, socket, or port 8889), so check the imported settings before relying on them.

The AI Administrator can drive this end-to-end with run_migration, but only after detecting sources and confirming with you — and only with changes enabled.

2.9Where your data lives

FrontierStack keeps its own state in predictable, standard places, so you always know what it touches and can back it up:

Keeping the app's Apache config in its own frontierstack/ directory means FrontierStack can manage vhosts safely without clobbering configuration you maintain by hand. The bundle identifier is jp.co.enfour.frontierstack (the helper and DDNS components use the .helper and .ddns suffixes).

With the app installed, the helper decided, Homebrew in place and any old stack migrated, you're ready to actually use it. Chapter 3, The Interface tours the window in detail: the sidebar, panes, search, the menu bar, and the controls you'll reach for every day.

FrontierStack manages an enormous range of services, yet it presents them through a single, familiar macOS window: a sidebar of things on the left, the screen for the selected thing in the centre, and a row of always-available tools in the toolbar. Learn this layout once and every pane in the book — from Apache to a Cloudflare zone — sits exactly where you expect it. This chapter walks the interface end to end so the rest of the manual can simply say "open the Sites pane" and trust that you know how.

3.1The main window

The window is a standard macOS NavigationSplitView with three regions. On the left is the service sidebar: a scrollable, collapsible list of every service and tool you have chosen to see, grouped into categories. In the centre is the active pane — the screen for whatever you selected in the sidebar, with its own header, tabs and controls. Running across the top is the toolbar, whose buttons are available no matter which pane you are in.

From right to left, the toolbar holds: Search (the magnifying glass, also ⌘F); the AI assistant (the wand, which opens the floating command palette); a Shell button that drops a terminal into the current working directory; a Dark mode toggle that forces dark even when macOS is in light; and, when the selected pane can be floated, a break-off button to pop it out as a palette. If you have unsaved changes to a Setup, an orange Unsaved menu appears here too.

The sidebar's width is yours to set — drag the divider and FrontierStack remembers it across launches. Your last-selected pane is restored when you reopen the app, so you return to where you left off.

Sidebar groups tame a sidebar that spans several sites or companies. Right-click any pinned server, device, Cloudflare zone, Wi-Fi network or cluster and assign it to a group ("Osaka office", "Acme Corp"); group rows at the top of the sidebar then switch between the sets, showing the active group's items plus everything ungrouped — grouping is optional, and ungrouped items are always visible. A red count on a non-active group warns that something hidden inside it has a problem, and a group linked to a Location activates itself when you arrive on that network. The iPhone app mirrors the same folders in its Fleet tab.

3.2The service sidebar

The sidebar is organised into two tiers. At the top sits Overview — the app's own built-in tools: Local Health, Status Page, Alerts, Domains, Logs, Certificates, Notes, Scripts, Setups, Settings and more. Below it, one section per service category — Web Servers, Databases, Caching, Mail, Networking, Security Tools, Containers, AI and dozens more — each listing the services you have chosen to show from the catalog (Chapter 6). Every section header is a chevron you can click to collapse, and the app remembers which groups you leave folded.

Each service row shows a status dot when it is running. Right-click a service for two quick actions: Pin to Top of Section keeps a service you touch often at the top of its category, and Hide removes it from the sidebar. Hiding never uninstalls anything — the service keeps running and stays reachable from Search; it just stops cluttering the list.

Below the categories, the sidebar grows extra sections for the things you pin elsewhere in the app: linked servers (each with little category icons showing which services it runs), monitored Wi-Fi networks, Cloudflare zones and Kubernetes clusters. Type in the filter field at the top of the sidebar to narrow every section at once.

3.3Presets and Setups

Two features shape what the sidebar shows. The Presets menu (in the menu bar) is the fast way to load a whole use-case at once. Its Base — show services for… section swaps the sidebar to a curated set for a scenario (a web stack, a mail server, a shop), while Add to current view… layers an extra group onto what you already have. Show All reveals everything; it is the escape hatch when you cannot find something.

Setups go further: a Setup is a named snapshot of your whole working view — which services are hidden, which are pinned, and the floating palettes you have open and where they sit. Save one from Presets ▸ Save Current as Setup… (or from the Setups pane), then flip between Setups from the top of the Presets menu; the active one carries a check mark. The palette layout auto-saves into the active Setup as you move windows around, so a Setup always reflects how you really work. Change which services are shown and the Setup goes dirty; the toolbar shows an orange Unsaved badge with Update, Save as New and Revert.

A Setup can also be bound to a Location (Chapter 8). Bind your "Office" Setup to your office network and FrontierStack switches to it automatically when you arrive — the right services, the right palettes, for where you are.

3.4Floating palettes and mini-palettes

Sometimes you want to keep one screen visible while you work elsewhere. Any monitor-style pane can be broken off into a floating palette: a small, always-on-top utility window built on macOS NSPanel, so it stays above the main window and other apps. Use the break-off button in the toolbar (or ⌘⌥⇧W to close the front palette). Local Health, Containers, Cloud Servers, the Wi-Fi Analyzer and others all float.

For an even lighter footprint there are mini-palettes — compact, glanceable summaries rather than the full pane. Minis exist for Local Health, Cloudflare Zones, Wi-Fi, Printers, Router & Network, Containers, Scripts, Message Delivery and AWS. Each mini row has a button to open the matching pane in the main window when you need the detail. Open palettes are part of a Setup, so a saved view restores your floating windows exactly as you arranged them.

3.5The command and AI palette

The wand button in the toolbar opens the AI assistant palette — a draggable, always-on-top NSPanel with a single ask-anything field ("why is my site down?", "tune MySQL", "show only what I use"). It is the same AI Administrator covered in Chapter 13, surfaced as a floating window you can keep beside whatever you are doing. Like every floating palette it stays above the main window; unlike the others it talks back, proposes fixes and — with your approval — acts. It carries its own conversation history and an approval card for any mutating action, so nothing runs until you say so.

3.6The menu-bar item

FrontierStack can place a small item in the macOS menu bar (toggle Show in Menu Bar). It is the quickest way to act without bringing the whole window forward. From it you can Start or Stop your startup group, Restart any of the core servers (Apache, Nginx, PHP-FPM, MySQL, Postgres) or everything running at once, refresh status, set Launch at Login, and open or quit the app.

The Localhost section lists what this Mac is actually serving right now: each entry is a web UI found by probing the ports that really have a listener (dev servers such as Vite on any port, admin consoles, Apache or Nginx on 80/443), and one click opens it in your browser. A port published by a running Docker container shows the container’s name, and a Containers running row jumps straight to the Docker pane. The list refreshes each time the menu opens; Refresh Status forces a new scan immediately.

3.7In-app Search

Search (the magnifying glass, ⌘F) is the fastest way to reach anything. Start typing "search services, tools & actions…" and the palette matches panes, tools, services and actions as you go — including services you have hidden from the sidebar. Pick a result and the app navigates straight to it. A Semantic mode lets you search by meaning ("block an IP", "free up disk") rather than exact names, so you can find a capability without knowing what FrontierStack calls it.

3.8The Help window

Open Help with ⌘? for a dedicated FrontierStack Help window. It is a real book of in-app documentation, organised to mirror the app. Help is more than reading: its pages carry Open in app links. Click one and FrontierStack jumps the main window to that exact pane or service — the Help window stays open beside it, so you can read a procedure and follow along step by step. Many panes have a small help button in their header that opens Help at the matching topic.

3.9The Notes pane

Notes is your private place for credentials, runbooks and per-service instructions. Each note has a title, a service tag and a body, and the whole thing is encrypted in the macOS Keychain — not stored in plain files. The defining feature is the per-note lock: every note carries a Share with AI Administrator toggle that is off by default. While a note is locked, the AI literally cannot read it. Unlock a note only when you want the assistant to use those credentials or steps; it then appears in the AI's list_notes and can be read on demand.

3.10The Status Page

The Status Page pane publishes a static index.html built from the same up/down data as Local Health, so customers or colleagues can see what is running without access to the app. Choose a destination — a folder inside one of your Apache sites' DocumentRoots, so it is served at a path like /status/ — set a page title, and decide whether to Include item details (leave detail lines off for a public page, since they can reveal internal hosts and ports). The page regenerates on an interval you set, or on demand with Generate Now. Serve with picks Apache or the built-in server (a bundled static file server on a port of your choice, localhost or LAN), and Launch keeps that server running at login or at system start so the page outlives the app. A Servers section can list pinned servers with monitors, kept live even while the app is closed, and Internet access offers persistent routes (Cloudflare Tunnel, Tailscale, router port-forward with Dynamic DNS). Chapter 11 has the details.

3.11Local Health and Locations at a glance

Two Overview panes anchor everyday use, and each has a full chapter of its own. Local Health is the board that answers "is everything OK?": every monitored service, device and subsystem with an UP or DOWN state and a one-line summary. You mark items as critical from their own panes to add them to the board, and it doubles as a floating palette and a mini. Its full treatment — the health sweep, thresholds and how it drives alerts — is Chapter 11.

Locations teach the app where your Mac is on the network right now — Home, Office, On VPN — matched from the Wi-Fi network or subnet. Locations make monitoring network-aware: while you are somewhere unrecognised the app treats you as Away and pauses location-scoped checks, so a café or hotel network never sets off false alarms. They also bind Setups, as we saw above. The complete model — defining locations, scoping alerts and reachability, the fleet — is Chapter 8.

With the layout learned, you are ready to put it to work. The next part of the manual opens the panes themselves, starting with Chapter 4, The Web Stack.

A web server is the heart of most self-hosted setups, so FrontierStack treats it as a first-class citizen. The Apache pane installs, starts, validates and configures a Homebrew Apache; the PHP, Localhost, Certificates and DNS panes round out a complete development and hosting stack — and every change goes through validation so a typo never takes a site down silently.

This chapter covers the panes that make and run web sites on the Mac in front of you. Connecting that stack to a real domain and the public internet is Chapter 7; tightening it for production is Chapter 10.

4.1The Apache pane

Open the Apache pane from the sidebar to see your web server’s state at a glance: version, whether it is running, and the ports it listens on. The buttons across the top are the controls you reach for daily — Start, Stop, Restart and Validate Config. Validation runs apachectl -t (a real syntax check) and shows the result in Last Result, so you can confirm a change is sound before you reload.

FrontierStack recommends a Homebrew Apache rather than the macOS system copy. The Homebrew server lives under /opt/homebrew (or /usr/local on Intel Macs), runs as you through brew services without a root prompt for every action, and is not locked down by System Integrity Protection — so a current mod_php loads cleanly and the whole stack stays on one toolchain. The system Apache under /etc/apache2 is wiped by OS updates and ties you to Apple’s bundled libphp. If Homebrew Apache is not installed, the pane offers Install Homebrew Apache… in one click.

If you keep several Apache builds — the Homebrew one, a legacy local build, or a remote server’s — the binary picker (see Add Homebrew Apache / Add Local Build…) lets you register and switch between them, each with its own version and ports shown.

4.2Modules, ports and the managed config

Lower in the Apache pane are the parts of the config you most often edit, each surfaced as a control rather than a file:

For anything not exposed as a control, the config rows give you Edit Managed Config… (the FrontierStack include) and Edit httpd.conf… (the main file) directly. Every save validates with apachectl -t, reloads gracefully, and rolls back if the new config does not parse — so a bad edit is caught before it can break the running server.

Toggling a module rewrites its LoadModule line and revalidates. If a change leaves httpd -t failing — the classic case is enabling proxy_fcgi without proxy, which the app now auto-enables for you — the Modules window shows the error and won’t close silently: you either correct it or choose Save anyway. When Apache is wedged and won’t start (the classic Homebrew Bootstrap failed: 5: Input/output error, from a service that was already loaded, or from sudo brew services leaving some httpd paths owned by root), the pane’s Recovery & reset section offers three escalating fixes: Restart cleanly (stops httpd in both the user and system launchd domains, then starts it once), Reset config to default (backs up your httpd.conf and restores Homebrew’s), and Remove & Reinstall (clears the root-owned paths and reinstalls the formula). All run in the in-app console so you see the sudo prompt and output. If Service Watchdog keep-alive is also on for Apache, it may restart httpd on its own — expected, but pause it if it fights a manual recovery.

4.3Choosing the PHP version

Open the PHP pane to manage the PHP runtimes installed on the Mac. Homebrew lets several major versions live side by side (for example [email protected] through the current release), and FrontierStack treats them as a set you switch between rather than a single global install.

Version ▸ Add Version… installs another version alongside the ones already there — nothing is replaced, and the version you are using does not change. The list has two parts. Homebrew’s own releases are the ones still supported upstream. Below them sit the end-of-life builds — PHP 8.0 back to 5.6 — which PHP itself no longer patches and Homebrew has dropped; FrontierStack fetches those from the community shivammathur/php tap, and asks you to confirm each one first, because installing from a tap means running that tap’s own code. Keep an end-of-life PHP for testing or maintaining a legacy site on your own machine, and never point the public internet at it.

There are two distinct choices:

• The Apache module. In the Apache pane’s PHP Module section, the Load for websites picker chooses which version’s libphp.so Apache loads. Changing it rewrites the managed config and reloads Apache.
• Per-site PHP. A local dev server (the Localhost pane, below) has its own PHP Version picker listing every installed version, so one project can run on an older PHP while another runs on the latest — without changing what the rest of the machine uses. This is the usual way to keep a legacy app and a new one happy at the same time. It applies to both local runtimes: the PHP built-in server and the Apache runtime. One caveat for Apache, which serves through mod_php: a version is only usable there if its keg ships libphp.so, and the editor tells you when the one you picked does not. When it does not, run that site on the built-in server, or serve it through PHP-FPM.

The Runtime Health pane gives the wider picture — PHP alongside Python, Node.js, Java, Go, Rust, Ruby, Perl and .NET — with a self-check that flags a missing or end-of-life runtime before it bites you.

The Runtimes section also carries a React pane for front-end work. It scaffolds a new app (Vite, TanStack Start or Next.js), points at any React project, and offers a curated companion-library list filed by the job each does — state management (Zustand, Jotai, Redux Toolkit), data fetching and server state (TanStack Query — the library formerly called React Query — and SWR), full-stack frameworks (TanStack Start, Next.js), routing, validation (ArkType, Zod), forms, and authentication (Clerk). Each row shows its docs, whether the selected project already uses it, and a one-click npm install into that project.

4.4Sites and virtual hosts

The Websites list in the Apache pane is where you manage virtual hosts. Each row shows the site’s name, the bind address and the port (for example :8080), and a Running toggle for its live status. The buttons let you Add Site…, edit, duplicate, disable, Push to Server… (copy a vhost to a linked server), and open the site in a browser. Import Sites… and Copy from… pull existing vhosts in from MAMP, XAMPP, Apple’s Server.app or another Apache, bound to localhost by default.

Adding or editing a site, you set the essentials a vhost needs: its ServerName (the domain), the document root (Choose… a folder), and the bind address and port. Enable the site and it appears in the list with a live status dot; FrontierStack writes the vhost into a .conf file under the managed tree, validates, and reloads. To create the vhost, certificate and a Cloudflare DNS record together, use New Site + DNS… — the one-flow wizard described in Chapter 7.

4.5TLS certificates for sites

The Certificates pane issues and manages the certificates that put the padlock on your sites. It offers three paths, suited to different needs:

Once issued, Deploy to Apache wires the certificate into the site’s vhost. The Expiry Monitoring section watches your certificates (and any domain you add with Watch) and alerts you well before they lapse — the deeper hardening story, including HSTS and modern cipher policy, is in Chapter 10.

4.6The .htaccess editor

Per-directory Apache rules — rewrites, redirects, access control — live in .htaccess files, and FrontierStack gives them a dedicated editor with line numbers and a syntax sanity check. Open a site’s document-root .htaccess with Use Site Root, or point it at a custom path. Insert Recipe drops in common, correct snippets (a front-controller rewrite, a force-HTTPS block) so you start from working rules rather than memory, and the editor flags obvious problems before you save. Export PHP Router… turns .htaccess rewrite rules into a router file for a built-in PHP dev server — useful when you move a site to the Localhost pane.

4.7Nginx and reverse proxies

FrontierStack manages Nginx as an alternative web server or a reverse proxy in front of an app. When both are installed, the Domains view groups your sites by server — Apache virtual hosts and Nginx server blocks side by side — reading each Nginx server block’s listen port, root and TLS state. A reverse proxy is the standard pattern for fronting an application that speaks HTTP on a high port (a Node, .NET or Python service): Nginx terminates TLS on 443 and forwards to the app. Because Apache and Nginx both want 80/443 by default, use the Apache pane’s Ports section to move one off those ports if you run them together.

4.8Localhost, DNS and dev stacks

Three more panes complete the local picture:

• Localhost — a manager for ad-hoc local dev servers. Add a New Local Server, pick a Runtime (PHP, Python/Django, Node/Vite…) and folder, set a port and an optional ServerName, and Start it — with per-server Environment Globals and a .test resolver so myapp.test resolves locally. A Free Port helper and a stop whatever is holding localhost action clear the usual conflicts. Tick Also serve on Tailscale to reach a server from your other Tailscale devices at this Mac’s tailnet address on the same port — the server still listens on localhost only and FrontierStack forwards tailnet connections to it, so the LAN can’t reach it. For a Django server, Allow Tailscale Host… adds the tailnet address to the project’s ALLOWED_HOSTS after showing you the change (or hands you the line to add, when the setting is built from environment variables). The AI Administrator (and an agent over MCP) can start a folder the same way with debug_share action serve; the reply names the localhost host and port and, when asked, the Tailscale URL, so the agent can report where the site is running.
• DNS — local name resolution and authoritative hosting. Run dnsmasq, unbound or nsd; import and export zone files; and flush the resolver when records change so the Mac stops serving a stale answer.
• LAMP / DevStacks — one-click stacks. The LAMP pane offers presets (Choose a Setup) that install and start a matched set of components together (Install & Start, Start All, Stop All); DevStacks detects the framework of a project folder and shows the right commands and npm scripts to run it.

An Localhost overview shows every local server you have running, side by side, so you can run many sites at once without a wall of Terminal windows to babysit.

A web stack is only as good as the data underneath it. FrontierStack treats databases as first-class services: it installs and runs them, browses what is inside, lets the AI Administrator inspect and repair a site's database in plain language, and — the part most setups forget — backs everything up on a verified schedule that you can actually restore from. This chapter covers the relational engines, the in-memory caches, the newer vector and analytics stores, and the backup machinery that protects them all.

5.1The MySQL / MariaDB pane

Open MySQL from the Databases section of the sidebar. The pane installs the server through Homebrew if it isn't present, then gives you the controls Server.app used to: Start, Stop and a live status light, the listening port (default 3306), and a list of the databases on the server. MariaDB — the drop-in MySQL-compatible fork — is managed the same way; the pane recognises whichever is installed.

Local development follows one deliberate convention: the local root account has no password. This is the MAMP/XAMPP norm and it is what makes one-click setup and the AI's SQL tools work without a credential prompt. It is safe precisely because MySQL on your Mac listens only on 127.0.0.1 and is reachable only from the machine itself. The moment a database needs to be reached from elsewhere — a passworded account, or a database on a linked server — you switch to the secret vault, described below.

5.2Database Ops and running SQL

The Database Ops pane is where databases stop being a black box. Its Replication section detects whether a configured server is a MySQL replica or a PostgreSQL standby and shows the lag: MySQL reads SHOW REPLICA STATUS (IO and SQL threads, Seconds_Behind_Source); PostgreSQL uses pg_is_in_recovery() and the replay timestamp. Stopped replication, or lag past your threshold, raises an alert on your channels — the basis of the Database Slave monitoring preset.

For inspecting or fixing data, the AI Administrator carries a run_sql tool. Ask it in plain language — "why are these orders showing the wrong total?", "delete the duplicate users older than the originals" — and it runs SQL against the local server and shows you the result as a table, much like MAMP's Claude integration. Because statements can modify data, run_sql requires changes enabled; read-only queries work the moment the assistant is on. It defaults to local root with no password and is local-only by design.

5.3Passworded and remote databases

The local-root shortcut stops exactly where the network begins. For a database that needs a password, or one on a remote or linked server, you never paste the password into a prompt or a tool. Instead you add it once to the AI Administrator's Script secrets (.env) bar as a named secret — DB_PASSWORD or MYSQL_PWD — and the assistant runs the mysql client through run_script, referencing the value as $DB_PASSWORD and running it over SSH against the named server. The real value stays on your Mac and is injected at run time; the cloud model sees the name, never the secret.

5.4PostgreSQL

Open Postgres for projects that want advanced SQL, rich JSON, full-text search or GIS. The pane installs and runs PostgreSQL (default port 5432) and sits alongside MySQL with the same start/stop/status controls. Choose PostgreSQL when your application or framework expects it; otherwise MySQL/MariaDB remains the easy default. Both engines are first-class targets for the backup jobs and AI tools described later, and PostgreSQL is the foundation for several of the specialised stores below — pgvector for embeddings, TimescaleDB for time-series, and PostgREST for an instant REST API over a Postgres database.

5.5Redis and other caches

Sessions, queues, rate limits and hot-path caching usually want an in-memory store rather than a relational table. FrontierStack runs the two standards from the Caching catalog: Redis (port 6379), the in-memory key-value store that also backs Redis Streams, and Memcached (port 11211) for a simple distributed cache. Install, start and monitor them like any other service. Most CMS and framework deployments pair Redis with MySQL or PostgreSQL; the Service Catalog (Chapter 6) lists every option.

5.6Vector and analytics databases

Two newer families of store get their own catalog categories. Vector databases hold embeddings for retrieval-augmented generation (RAG) and semantic search; they are how the AI stack (Chapter 15) gives a model access to your own documents. Analytics databases are columnar or time-series engines built for fast aggregation over large datasets rather than transactional reads and writes.

For purely in-process vector search there is also FAISS (a library, no port). Pick the engine your framework expects; the panes install and run each one through the same catalog machinery.

5.7Data pipelines & ETL

Moving and reshaping data between these stores is its own discipline. The Data Pipelines & ETL catalog category covers it at the overview level: Airbyte and Meltano for extract-load with hundreds of connectors, dbt for SQL-based transformation and modelling, and orchestrators such as Dagster, Prefect and Kestra for scheduling the work. These are full platforms; FrontierStack installs and runs them and surfaces their web UIs, but the pipeline logic lives in each tool. For programmatic data-pipeline DAGs there is also Apache Airflow in the Workflow Orchestration category.

5.8Backups: dumps, the overview pane, and CCC

A database with no tested backup is a future outage. FrontierStack approaches this from two directions. In Database Ops you define a verified dump schedule per server: name, engine (MySQL or PostgreSQL), host, port, user, database (blank = all) and a backup directory. Due jobs run automatically while the app is open, and Run Now triggers one immediately. Each run does more than dump — mysqldump runs with --single-transaction for a consistent InnoDB snapshot, then Verify checks gzip integrity and that the dump ends with its completion marker (catching truncated or half-written files), writes an .md5 sidecar, rotates to your keep count, and rsyncs the result offsite over key-based SSH.

The AI Administrator exposes the same operations as tools: db_dump dumps a database to a .sql file on the target (using mysqldump or pg_dump), and backup_now makes a timestamped tar.gz of configs, a site or a data folder. Both are mutating, so they require approval and changes enabled; for the DB password they reference a $NAME vault secret, never a pasted value.

The Backups overview pane rolls up every mechanism so staleness is obvious at a glance: Time Machine status, Carbon Copy Cloner tasks, app-managed Apache config snapshots, config version history in Git, and scheduled auto-exports. The Carbon Copy Cloner pane reads CCC's tasks and history through its ccc command-line tool and lets you Run a task on demand. Both Time Machine and CCC feed the Alerts engine — a backup that hasn't run within its threshold, or a failed CCC task, raises an alert on your channels (Chapter 11).

The app's own settings are covered as well. The sidebar's pins and hidden services, saved Setups and network Locations are kept in JSON files in the app's support folder rather than only in macOS preferences; every Git snapshot carries them together with a copy of the preferences, and an hourly shadow copy of the preferences means a wiped preferences file is put back automatically at the next launch. Restore App Settings… under Config version history restores them by hand from the latest snapshot.

5.9Restore — and restore safety

Backups exist to be restored, and restore is the dangerous half. The AI's restore tool extracts a .tar.gz archive or imports a .sql dump into a database. Because importing a dump overwrites the live database and extracting an archive overwrites files in place, restore is mutating and potentially destructive: it always requires explicit approval with changes enabled, and SQL imports reference the DB password as a $NAME vault secret.

5.10Recovering a broken database

Sometimes a database is worse than down — it won't start, or a table is corrupt. FrontierStack gives the AI Administrator (Chapter 13) the same tools you would reach for by hand, behind the usual approval card. mysql_check_tables and pg_check_tables run mysqlcheck / pg_amcheck to find corrupt or crashed tables; with repair on they take a mysqldump/pg_dump backup first, then repair (--auto-repair / REINDEX), so a fix is reversible. mysql_service_control and pg_service_control start, stop, restart or check the server across systemd, launchd, Homebrew or service(8), local or over SSH.

For the hard cases there are guided skills — “Recover Broken MySQL” and “Recover Broken PostgreSQL” — that walk the whole runbook: read the error log, diagnose the fault, dump everything readable, rebuild into a fresh data directory, repair or recreate the damaged tables, and restart — always renaming the old data directory aside as a cold backup, never deleting it, and confirming before every destructive step. On a remote host, the fastest way in is the red Emergency button on the database's row in the server pane: it opens the assistant pre-loaded with the right recovery skill for that host.

5.11ORMs and app-native tooling: Drizzle and Convex

Finally, two tools meet your application where it defines its schema. The Drizzle ORM pane detects a Drizzle project (its tables, migrations and backend dialect) and runs drizzle-kit tasks for you — Generate SQL from your schema, Migrate, Push the schema directly, Pull (introspect) an existing database, and open Drizzle Studio to browse data. The Convex pane manages Convex, a reactive backend with a built-in database: run npx convex dev to watch and push functions, or stand up a self-hosted backend in Docker. Both need Node.js, which the panes will install via Homebrew if it is missing. These cover the application's own data layer; the dumps and backups above still protect whatever they write underneath.

FrontierStack ships a catalog of 1626+ services across 113 categories. Every entry can be discovered, installed, started, configured and monitored from the app — and the AI Administrator can act on any of them. This chapter is the field guide: each category, what lives in it, and a one-line description of every service. Service descriptions are kept in English so they match the labels in the app.

Each service also has its own page on the website at frontierstack.app/services/ with ports, default web UI and the Homebrew formula.

6.1Overview

6.2Setup & Migration

6.3Locations & Places

6.4Fleet & Remote

6.5Networking

6.6VPN

6.7Routers & Firewalls

6.8Web Servers

6.9DNS

6.10Runtimes

6.11Databases

6.12Vector Databases

6.13Analytics Databases

6.14Data Pipelines & ETL

6.15Caching

6.16Search

6.17Backup

6.18Storage & NAS

6.19Object Storage & S3-Compatible

6.20Mail

6.21Mailing Lists

6.22Email Deliverability & Reputation

6.23Message Queues & Streaming

6.24Push Services

6.25Chat & Collaboration

6.26SMS & iMessage Gateways

6.27Business Messaging

6.28Calendars

6.29Identity & Accounts

6.30Customer Identity

6.31Decentralized Identity

6.32Version Control

6.33CI/CD

6.34Build & Compile

6.35Internal Developer Portals

6.36Infrastructure as Code

6.37API Testing & Synthetic Monitoring

6.38Proxies & Load Balancers

6.39Proxy Gateways

6.40CDN & Edge

6.41Hosting

6.42AWS Control

6.43AI / LLMs

6.44AI Clusters

6.45Agent Platforms

6.46FinOps & Cloud Cost

6.47Containers

6.48Service Mesh (Kubernetes)

6.49Apps & CMS

6.50Knowledge & Memory

6.51E-Commerce

6.52QR & Link Management

6.53Student Information Systems

6.54Learning Management

6.55Digital Library

6.56Campus & School Ops

6.57Sourcing & Suppliers

6.58Print-on-Demand

6.59Shipping & Fulfilment

6.60Inventory Sync

6.61Profit Analytics

6.62Mesh Networking

6.63Anonymity Networks

6.64Secrets & Vaults

6.65Monitoring

6.66Security Tools

6.67SIEM & Security Data

6.68Secrets Scanning & Supply Chain Security

6.69Policy, Compliance & Governance

6.70MDM & Device Management

6.71Logging & Observability

6.72Incident Management & On-Call

6.73Status Pages

6.74Mining

6.75ML Workbench

6.76AI Governance & Safety

6.77GPU Infrastructure

6.78Speech AI

6.79Image & Video AI

6.80MCP

6.81Self-Hosted Apps

6.82Web3

6.83Crypto

6.84RPC Services

6.85Tools

6.86Home Automation

6.87Cameras

6.88IoT

6.89MQTT Brokers

6.90POS Systems

6.91CRM & Loyalty

6.92Helpdesk & Ticketing

6.93IT Assets

6.94Project Management

6.95PMS

6.96Meeting Rooms & Desk Booking

6.97Coworking & Shared Spaces

6.98Facilities & Maintenance

6.99Accounting & ERP

6.100Healthcare

6.101Automation & Workflows

6.102Workflow Orchestration

6.103HRIS Integration

6.104VoIP & Telephony

6.105Contact Centre & IVR

6.106SEO & Marketing

6.107Conversion Rate Optimization

6.108Social Media

6.109Media Servers

6.110Download Automation

6.111AV & Stage

6.112Render Farm

6.113Tracking & Telematics

A working website is more than a running Apache. The domain has to resolve, the certificate has to be valid, the right machine has to answer, the CDN has to be in front of it, and the search engines have to know it exists. FrontierStack gathers all of that into the Sites pane and a small family of companion tools, so the whole chain — registrar, DNS, TLS, CDN, host, SEO — is visible and fixable from one window. This chapter covers the web above the stack; for the vhosts and certificates themselves see Chapter 4.

7.1The Sites pane and Domain Health

Open Sites from the sidebar. At the top sits the Domain Health section, a live dashboard that collects every hostname FrontierStack knows about: the local Apache and Nginx vhosts you have defined, the vhosts on linked servers, every Cloudflare zone on your token, and every domain in the registrar monitor. Each domain gets a row with a set of status badges; press Check on a row, or Check All in the header, and the app probes the domain end to end and colours the badges green or amber.

The point of the dashboard is to answer one question reliably: is this domain actually serving, and from where? Because the checks run against the public internet (a real DNS lookup, a real HTTP request, a real TLS handshake), they catch the failures a local config check never sees — a record that points at the wrong IP, an expired certificate, a Cloudflare zone stuck in "pending", a site that resolves but returns a 502.

7.2ChatGPT Sites: monitor, use your domain, or self-host

The ChatGPT Sites section uses one shared registry everywhere it appears in FrontierStack. Paste a public name.openai.chatgpt.site URL and it joins Domain Health, SEO and Alerts like any other site. Mark a workspace- or owner-only Site private and outside probes pause, because its sign-in page is not an outage.

Import or Move offers two owner-authorised routes. Use my domain keeps the Site on ChatGPT: first add the domain in the Site's ChatGPT settings, then copy the exact DNS records ChatGPT supplies. FrontierStack validates that every record belongs to the selected Cloudflare zone and publishes it DNS-only; for another DNS provider, add the records there and use Save Domain. Both paths keep the original Sites address and the custom domain in the registry. Return to ChatGPT and refresh the domain status after DNS propagates.

Self-host starts from the Site's local project folder. FrontierStack reads .openai/hosting.json and package.json, identifies the framework and ready output folder, shows D1/R2 bindings and the names of example environment variables, and copies the reviewed web output into a managed Apache domain. The importer never runs package scripts, never reads secret values, skips links and source-control metadata, limits the copy to 50,000 files or 5 GB, and uses a staging folder so a failed replacement can be rolled back. Build the project first, then import dist, build, out, public, or another folder containing index.html.

7.3Proving domain ownership

Vendors verify that a domain is yours by asking you to publish a DNS TXT record only its owner could create — the same proof-by-DNS idea as ACME's DNS-01 challenge, but every vendor has its own record format. The Verify button on a Domain Health row keeps those formats in one place: pick the service — Google (Search Console / Workspace), Microsoft 365, Meta, Apple Business Manager, Atlassian, OpenAI, Stripe, GitHub organizations, or a custom record — paste the token from the vendor's console, and FrontierStack publishes the TXT record straight into the domain's Cloudflare zone. If the domain isn't on your Cloudflare token, it hands you the exact record to add at your DNS host instead. A bare token is completed automatically (paste abc123 for Google and the record becomes google-site-verification=abc123).

The sheet also shows the verification records already published on the apex — a quick audit of who this domain is currently proven to — and Check DNS queries public DNS (1.1.1.1) for the new record, so you know the proof is visible before you press "Verify" on the vendor's side.

For certificates, the Let's Encrypt service pane (Security & Secrets category) is a standing health check on the other kind of domain proof: it watches the ACME API, Let's Encrypt's status page and a domain's live certificate, and — because ACME clients renew when 30 days remain — alerts when a certificate is overdue for renewal, catching broken certbot/acme.sh automation weeks before visitors ever see an expiry warning.

7.4AI SEO and "Fix My Site"

Two of the badges on a domain row are not just diagnostics — they are buttons that hand the problem to the AI Administrator. Fix My Site takes a broken or misbehaving site and runs the assistant through a fixed playbook: reproduce the fault by curling the site locally with its Host header, read the relevant logs, check that Apache, PHP and the database are running, and then state the single most likely root cause with concrete next steps. With Allow changes off it only advises; with it on it may apply the reversible fixes (restart a service, correct a wrong value in a config file, repair the database). There is a WordPress-aware variant for the classic white screen, "Error establishing a database connection", broken permalinks and stuck maintenance mode.

The SEO action runs an on-device read-only audit: the assistant fetches the home page, robots.txt and the sitemap, scores the site out of 100 and writes a short report (titles, meta descriptions, headings, crawlability, structured data). The result opens in an SEO report sheet so you can read the findings and act on them.

7.5One-click CMS installs (Apps & CMS)

WordPress gets a single pane that both installs new sites and runs the ones you already have — on this Mac or on any fleet server. That merge matters: the old installer pane could only ever write to This Mac, whereas everything here runs through WP-CLI on whichever host you pick, so a remote server is a first-class target for a new install. Install a new WordPress site, at the foot of the pane, downloads WordPress onto the selected host, writes wp-config.php, creates the database and completes setup with the administrator account you name. Nothing is copied up from your Mac, and an install already sitting at that path is refused rather than overwritten. Serving the new folder still needs a virtual host — create one in the Sites pane for a local site, or on the server's own web server. Installing a CMS is only the first day of its life, and the same pane covers the rest. Choose a host — This Mac or any fleet server — and scan for wp-config.php under the usual web roots, and every WordPress install on that machine appears with its core, plugin and theme versions and whatever is waiting to be updated. Update all exports the database before it touches anything, because a bad plugin update is recoverable and a lost database is not. Check integrity compares the core files against the checksums WordPress.org publishes, which is the quickest way to find a defaced or backdoored install; add a free WPScan token and the pane also checks your installed plugins and core against the vulnerability database, marking anything with no published fix. Multisite networks list their subsites. Each site also carries an Add a plugin list — a curated catalogue covering booking, commerce, mail delivery, backups, caching and security — which installs straight onto that site, local or remote, with an option to activate it once installed. The list is deliberately not a mirror of the WordPress.org directory: every entry either fails visibly when it breaks or produces something FrontierStack already monitors elsewhere, and each says what the app can tell you about it once it is running, so an install never implies monitoring that does not exist. Anything already on the site shows as installed rather than being offered twice, and a premium plugin with no WordPress.org slug links to its own page instead. On a host with no WordPress site yet — or without WP-CLI — the catalogue is still shown, greyed out and not selectable, so you can see what will be on offer instead of meeting an empty pane. The remaining jobs are the ones that otherwise mean an SSH session and a half-remembered command: resetting the password of a locked-out administrator, search-replace to move a site between domains (WP-CLI rewrites URLs buried in serialized PHP, where a plain SQL replace corrupts them — so always dry-run first), cloning a site to staging, and exporting or optimising the database. A clone copies the files, gives the copy its own database, rewrites the URLs inside it and sets it to discourage search engines, so staging can never write to production or outrank it. Everything runs through WP-CLI over SSH, and the pane offers to install WP-CLI on any host that lacks it. Pin a site and Alerts will tell you about pending updates, a failed integrity check or a new vulnerability.

If your WordPress lives on managed hosting rather than your own machines, the hosting panes now list those sites too: WP Engine, Kinsta, Cloudways and Pressable each pull your installs through their API — environment, primary domain and status — and they roll up into Cloud Servers alongside your VPS instances, so one inventory covers everything you run. These are sites rather than machines, so they carry no power controls.

The Apps & CMS section installs the other self-hosted CMS onto your Apache/PHP/MySQL stack in a single flow, each with its own pane: Drupal, Joomla, Statamic, Grav, Kirby, Craft CMS and FreshRSS. The installer downloads the app (or runs composer create-project for the Composer-based Statamic and Craft), extracts it into the document root, and — for the ones that need a database (Drupal, Joomla, Craft) — creates the database and user and writes the config where the app expects it. The flat-file CMS (Grav, Kirby, Statamic) need no database at all. It then opens the app's setup or admin page so you can create your account (/admin, /panel, /cp, /admin/install…), while FrontierStack wires the virtual host, PHP and trusted HTTPS around it. For the install folder you can pick a site Apache already manages — a menu prefills its domain, document root and port — or Choose… a new empty folder; a matching Apache vhost is created for a new folder, or updated when the domain is an existing site. If an install misbehaves, Fix My Site (AI) above debugs it.

FreshRSS is the exception that finishes the job. It is a self-hosted RSS and Atom reader, and unlike the CMS above it leaves you no setup wizard at all: name an account and password in the pane, and the installer downloads the release, creates the database, runs FreshRSS's own command-line installer to write its configuration and build the schema, creates that account, and registers a virtual host pointing at p/ — the subfolder FreshRSS actually serves from, with the rest of its code left outside the web root where it belongs. The browser then opens on the login screen of a working reader rather than on step one of an installation. Because its API is Google Reader-compatible, mobile clients such as Reeder and NetNewsWire can sync against it once you expose it, which makes it a natural companion to the HTTPS and remote-access work elsewhere in this book.

7.6The Domain Registrar monitor

Sites tells you whether a domain works today; the Domain Registrars pane (in the DNS category) tells you whether it will keep working. Add a domain and FrontierStack watches three things on a schedule and raises an alert when any of them drifts:

• Expiry — the registration end date, registrar and nameservers, pulled over RDAP (with a whois fallback). Works for any domain, whatever the registrar.
• DNS — whether the domain still resolves (dig).
• SSL — the certificate expiry, checked directly with openssl.

A renewal warning fires when the expiry is within your reminder window, already past, or when auto-renew is off. For supported registrars the pane can import your domain list and auto-renew status by API — GoDaddy, Porkbun, Gandi, Value Domain, Route 53 (via the AWS CLI) and Cloudflare (reusing the Cloudflare token — this one needs a user API token, as Cloudflare Registrar does not accept account-owned cfat_ tokens). Registrars without a usable list API (Namecheap, Squarespace, Onamae) you add by hand; RDAP still monitors them.

7.7Cloudflare: zones, DNS, cache and tunnels

The Cloudflare pane is where you paste an API token and choose which zones appear in the sidebar. Each zone you Pin to sidebar becomes its own pane with that zone's Cloudflare/DNS/HTTP/SSL health, DDoS and bot protection, WAF rules, Workers, CDN analytics, development mode and cache purging (everything, a list of URLs, or by prefix). Scope the token carefully: a read-only token lists zones, but DNS edits, certificate DNS-01 validation, Dev Mode, cache purge and zone creation each need their own permission, and creating a brand-new zone needs the account-level Zone · Zone · Edit permission. The pane links straight to Cloudflare's token templates, a Test Token button probes the live API and lists exactly which of those abilities the token has or lacks (reads are exercised directly; writes are probed with deliberately-invalid requests, so nothing is changed), and a Dashboard button deep-links into the Cloudflare web console for the current zone.

When a pinned zone shows a warning or its HTTP check has stopped answering, the pane's Diagnose button finds out why instead of leaving you with a coloured dot. It probes each layer of the serving path in order — the zone's state at Cloudflare, the public nameservers, DNS resolution, HTTPS through the edge (decoding Cloudflare's 52x errors: 521 origin down, 522 timeout, 524 the app or its database hanging, 525/526 origin TLS), the origin server's ports 80 and 443 directly, and finally the machine FrontierStack knows serves the domain: the local web server if that is this Mac, or a linked server's on-host monitor service states (a stopped mysql surfaces right in the report). When the public path is broken it also sweeps the fleet: which linked servers are up, which binds the origin IP, and which already serves this domain's vhost — so a host that went offline and took the sites' front-door IP with it is named directly, together with the server that could take over. Each layer is shown pass/fail, ending with a plain-language conclusion — which layer broke and what to do about it.

Cloudflare turns up across the app: the AI's dns_record tool writes records into a zone you manage and updates existing ones in place — including flipping a subdomain between proxied (orange cloud) and DNS-only — issue_certificate can validate over Cloudflare DNS-01, and email_auth_dns can publish SPF/DMARC for you (see Chapter 13). The same account also powers Cloudflare DDNS and the Cloudflare Tunnel for exposing a local site — both covered in Chapter 9.

7.8Hosting providers

Not everything you run lives on a Mac. The Hosting category brings VPS and managed providers into the same window. VPS providers — DigitalOcean, Vultr, Linode, Hetzner, Sakura and others — expose their servers through an API token: paste it, and the pane lists each server with plan, location, status and IP, and lets you power one on, off or restart with a confirmation. Dashboard-style providers (managed hosting such as Hostinger) store their token and surface quick links to the control panel, docs and sign-up. Either way the credential lives in the Keychain, and the servers you can reach over SSH become part of your fleet (Chapter 8).

7.9IndexNow: instant search-engine submission

When a page changes, you do not have to wait for a crawler to notice. IndexNow Manager (in SEO & Marketing) tells the participating engines — Bing, Yandex, Seznam, Naver and others — immediately. Pick one of your managed sites, press Install Key File, and FrontierStack writes the <key>.txt file into the site's document root so the engines can confirm you own the key; Verify checks it is being served. Then submit a single URL, fire off the pending queue, or feed it from a sitemap, and it can auto-submit on a schedule. Everything goes to api.indexnow.org, which fans out to all participating engines; the URL's host must match the selected site and its key.

7.10Site Transfer: copying sites between machines

Two tools move a site without a manual rsync dance. Copy Websites Between Apache handles the local case: when you have more than one Apache install on the Mac (say a Homebrew one and an old Server.app one), choose the source install, tick the sites you want, and FrontierStack copies their document roots and vhost definitions into the currently selected Apache. Sites with the same domain are overwritten, so it is also how you re-import after a migration.

To move a site to another machine, the AI's promote_site tool clones a local site to one named fleet host: it uploads the document root, writes the vhost (Apache or Nginx) on the far side, reloads the web server, and can add the Cloudflare A record pointing at the new host — the same steps as a manual fleet push, in one call.

7.11Provisioning a new web project

The pieces above combine into a single flow for standing up a project's infrastructure from nothing. The idea is a clean division of labour: your AI tool (over MCP) owns the code; FrontierStack owns the infrastructure. The built-in Provision Web Project skill walks the assistant through the recipe in order:

1. Discover — inventory the target, its privilege access, installed Apache/Nginx and connected DNS provider; identify or install missing prerequisites before making a public change.
2. Zone — cloudflare_zone_create makes the Cloudflare zone and returns the nameservers to set at the registrar (and tells you plainly if the token lacks account-level zone-create rights).
3. Vhost + folder — vhost_create defines the Apache/Nginx site. If you did not provide a document root, FrontierStack creates an empty platform-appropriate folder and reports its path. It does not design or generate site content.
4. DNS — dns_record points the name at the host.
5. TLS — issue_certificate issues a Let's Encrypt certificate.
6. Preview — a temporary share for a localhost test point (Chapter 9).
7. Promote — optionally promote_site clones it onto a fleet host.

Domain registration can join the front of this recipe through domain_register, so an agent can in principle buy the name, create the zone, stand up the vhost, issue the certificate and clone to the fleet — with every money-spending or system-changing step previewed for your approval first.

Everything so far has been about the Mac in front of you. This part of the manual widens the lens to the whole estate: the Linux boxes in a rack, a vintage Xserve still running macOS Server, a Raspberry Pi on a shelf, a cloud VPS, even a Windows host. You link each one once over SSH, and from then on FrontierStack treats them as a single fleet — running diagnostics, fanning commands out, deploying sites, and watching their health. It also keeps track of where this Mac is on the network, so a laptop that moves between home, office and a café doesn't fire false alarms about servers it simply can't see right now.

This chapter covers linking and running the fleet. Chapter 9 goes deeper on the network and perimeter, Chapter 10 on hardening and the security audits, and Chapter 11 on continuous monitoring and alerts. The AI Administrator can drive almost everything here over the same tools — see Chapter 13.

8.1Locations & Places

Open Locations & Places ▸ Locations. A location is simply a named network — Home, Office, On VPN — recognised from several signals: the Wi-Fi SSID, the router (gateway) MAC address, the Wi-Fi BSSID, the subnet prefix of your IP address (e.g. 192.168.1.), your public IP block, and whether a VPN is up. The header shows where you are right now (Now: Office), with the live snapshot beneath it: Wi-Fi name, IP, gateway and VPN state. Detection runs every 30 seconds.

When FrontierStack sees a network it doesn't recognise it offers a New network detected banner — click Add… to save it. You can also press Add Current Network as Location, then refine the criteria: a location matches when all the set criteria hold (with SSID and router MAC treated as any-of), so leaving a field blank simply ignores it. When several locations match, the most specific one wins rather than the first in the list. Use the Mode picker to pin a location manually instead of auto-detecting — handy when the signals are ambiguous.

Not all signals are equally trustworthy, and this matters more than it sounds. A subnet prefix is not an identity: home routers, cafés and hotels hand out 192.168.1.× everywhere, so a location defined only by its subnet would happily match a completely different building. The router MAC is the strongest signal — it is unique to one piece of hardware and readable without any special permission — which is why Update all criteria from current network is the one-click fix for a location that was saved before router matching existed.

8.17.1Pinning a place with GPS

For the awkward case — two sites that genuinely share a subnet and you would rather not fuss with MAC addresses — a location can also carry a GPS pin. Stand in the place, open the location and press Pin This Spot (GPS); a Radius slider sets how far counts as "here" (150 m by default, because indoor positioning is coarse and a site is a building, not a point).

The pin is a cross-reference, not a requirement. It does two things: it lets a weak match be confirmed, and — more usefully — it lets a wrong one be vetoed, so Home stops claiming a café that happens to use the same subnet. To keep that from ever making detection worse, a location identified only by shared criteria (a subnet, a VPN toggle) is no longer reported as confirmed when a position is available and contradicts it; you get Away / Unknown instead of a confident wrong answer.

Devices belong to Locations too. In Device Discovery, a monitored device's ⋯ menu ▸ Assign to Location places it at a specific site — or leave it Automatic, where it falls into whichever location owns its subnet. You can also set it from the device's own pane, and each location's row lists the devices assigned to it. Private subnets repeat between sites, so a device pinned elsewhere can land in a location by subnet; press its × in that list (or choose No Location) to remove it, and a matching subnet won't put it back. When the Mac arrives at a recognised location, FrontierStack checks those devices (skipping any seen recently, e.g. over VPN) and shows each one's status: green reachable, red if it should be here but isn't answering, and orange when it's on a Wi-Fi segment this Mac can't reach — usually a different access point or band, such as a 2.4 GHz-only sensor while the Mac is on 5 GHz. Orange means “can't verify from here”, not “gone”.

The point of all this is the Location-Dependent Monitoring section. Mark a device, Wi-Fi network, Cloudflare zone or watch as critical in Overview ▸ Alerts, then scope it here to Only at Office. That check is paused everywhere else: your NAS won't ring as DOWN from a hotel, and your home Wi-Fi won't alert as lost while you're at work. Paused items resume silently when you return. When the location itself changes, FrontierStack can post a local notification, send a "📍 Now at: Office" alert through your Messaging Gateways, or both.

8.2Linking a server over SSH

A server joins the fleet through the Link a Server sheet — reachable from a device's pane, from Device Discovery, or from the Cloud Servers and Remote Tools panes. Enter a name, the host or IP, the port, an SSH username (root, ubuntu, ec2-user…) and the login password. That password is used exactly once: the app installs this Mac's managed SSH key into the server's authorized_keys, then connects key-only from then on. Nothing is stored except the server's address — the password is discarded.

For a key-only server with no password login, expand Can't use a password? Install the key manually, copy the shown public key into the server's authorized_keys yourself, then link. Tick Also install the monitoring helper to set up the host monitor in the same step (covered below).

Linked servers carry a small green or red status dot for reachability. If it goes red with Permission denied (publickey) — typically after a server is reinstalled, or the key was never installed — the AI tool repair_ssh_access clears the stale host key and re-installs the managed key, using a one-time login password you keep as a vault secret. The password is read locally and re-installs key access; on success the dot turns green again.

The host's Status section also shows a Connection row: what actually carries the server's default route — the negotiated Ethernet rate (10 GbE, 2.5 GbE, 1 GbE), the Wi-Fi generation (Wi-Fi 7 = 802.11be, Wi-Fi 6E/6/5) with its channel width, or a VPN tunnel. It is read during the normal status probe on Linux, macOS and FreeBSD hosts, and reported by the host monitor agent (v1.17+) on agent-only hosts. The same row appears for This Mac, and on SNMP devices the Interfaces query now lists each port's negotiated link speed.

Each server also has a Connect via setting (in its Edit sheet) for interactive shells: plain SSH (default), mosh — which logs in over your SSH settings and then switches to its own UDP transport, so the session survives sleep, roaming and flaky links — or experimental SSH3 over QUIC/HTTP3, whose server can hide behind a secret URL on UDP 443. Open Shell and Open SSH honour the choice; probes and file transfers always stay on plain SSH. Both clients are in the Services catalogue (mosh via Homebrew, SSH3 via Go).

8.3The managed key and the saved sudo password

Key access lets the app connect, but many useful operations — reading /var/log, editing Apache config, reloading a firewall — need root on the server. FrontierStack handles this with a per-host sudo password, saved in the macOS Keychain (never in plain files). It is captured automatically when you link a server, and you can set or change it later in the host's pane or in the Remote Tools target section (the Sudo password field).

When a root-only command runs, the helper primes sudo's credential cache with that saved password over the SSH session, then runs the command. If no password is saved, root operations fall back to passwordless sudo -n and simply report "needs sudo" when that isn't configured. Because secrets are referenced by name, you can keep several — for example a distinct MySQL password per server in the .env vault.

8.4Fleet Run — one command across every node

Fleet & Remote ▸ Fleet Run fans a single operation out across all linked servers at once, or a selected subset, with a live per-host result. Pick your Targets (toggle hosts; the reachability dot shows which are up), choose an Operation, and press Run on N Server(s) — everything runs concurrently over SSH and each host reports back below, expandable to its full output.

Operations are OS-aware: a package update maps to apt, dnf, pacman, zypper, apk or brew depending on the host; a service restart tries systemd, then Homebrew. You never write per-OS commands by hand.

Fleet Run is the fastest way to spot drift: run Disk usage or Uptime & load to compare hosts at a glance, or use the file-checksum and health-check tools in Remote Tools (next) to find a config that's diverged across the fleet.

8.5Creating a container, here or on a server

Everywhere FrontierStack lists containers there is a Create Container… button, and they all open the same sheet: the Docker pane for this Mac, the same pane with a linked server chosen in the host picker, and the Docker tab of the Server Activity window. What you build runs on whichever target you started from — locally through the docker binary, or on a server over the SSH connection you already have.

Start from a preset or from blank. The presets cover plain images — nginx, PostgreSQL, MySQL, Redis, a throwaway Ubuntu shell — and every self-hostable service the app can run as a single container, such as n8n, Flowise, Langflow, Vaultwarden and Checkmk. Choosing one fills in its image, port, volumes and environment, all of which you can change. Services that need a docker-compose stack are installed from their own pane on this Mac instead, and the sheet names them so nothing looks missing.

Before anything happens the sheet shows the exact docker run line with secrets replaced by dots, and lets you copy it. Creating pulls the image first (unless you turn that off) and then runs it, streaming the output back into the sheet.

8.17.2The Containers board as a monitor

The Containers pane is not only a list. It carries a status dot that rolls every runtime on this Mac into a single verdict, so a glance at the sidebar tells you whether anything needs attention. Green means everything installed is healthy; orange means something is stopped or still being probed; red means an installed engine is down, or a container is unhealthy, restarting, or exited with an error. A runtime you have never installed is not a fault — green therefore reads as “everything present is happy”, not “everything is running”.

The sections follow the same order as the services list: Apple Containers, Docker, Kubernetes, OrbStack, container machines, then Vagrant. Kubernetes appears here read-only, showing the clusters you pinned in Kubernetes Clusters; pinning and per-cluster actions stay in that pane, which watches whole clusters wherever they run rather than only what is on this Mac. Where a runtime is not installed, the button opens the pane that installs it instead of sending you to a download page.

The pin button in the header opens a small floating palette: a single status bar with the overall dot and a running count, above a short list of what is running, with anything set up but idle grouped under Waiting. It is deliberately tiny — something to leave in a corner of the screen while you work elsewhere. Clicking any row jumps the main window to it.

8.17.3Docker Swarm

Swarm is not a separate product to install — it is built into the Docker engine, which is why FrontierStack monitors it from the Docker pane rather than giving it a pane of its own. When the engine you are looking at belongs to a swarm, a Docker Swarm section appears listing the cluster's nodes (ready or down, whether one is draining, and which are managers) and its services with their replica counts — 3/3 when a service has every task it asked for, 1/3 when it does not. The Server Activity window's Docker tab carries the same thing as a Swarm segment, so you can read a cluster from any linked server.

The state comes from docker info, which the pane already calls for engine health, so a machine that is not in a swarm costs nothing extra to check. One rule of Swarm shapes what you see: only a manager may list the cluster. Ask a worker and its daemon refuses, so on a worker FrontierStack tells you that plainly rather than showing empty tables that look like a failure.

8.17.4Ready-made stacks

Some things are not one container but several that are useless apart. Install Stack…, on the Containers pane and in the Server Activity window's Docker tab, sets up a whole group at once. Four ship with the app: the *arr media stack (Prowlarr, which holds the indexer list the others read, plus Sonarr for series, Radarr for films, Lidarr for music, Readarr for books, Bazarr for subtitles and a download client), Monitoring (Prometheus, Grafana and node-exporter), a Media server (Jellyfin, optionally with Jellyseerr for requests) and Immich, a self-hosted photo library that genuinely needs four containers — server, machine learning, Redis and PostgreSQL.

You choose which members to include, where the config and media folders live, the user and group the containers write as, and a port offset that moves the whole stack clear of something already listening. Published ports bind to 127.0.0.1 unless you say otherwise. FrontierStack then writes a docker-compose.yml into the project folder and runs docker compose up -d. Compose is what makes a stack a stack: the members share a network and address each other by name, which is why Sonarr's indexer setting can simply be http://prowlarr:9696.

8.17.5Apple containers, and the GUI we recommend

On Apple silicon, macOS can run Linux containers natively through Apple's own container command, where each container gets its own lightweight virtual machine instead of sharing one big Linux VM. The Containers pane has an Apple Containers section for this: it lists what is running, starts and stops the container system, pulls images, and creates new containers, in the same shape as the Docker section above. Apple's tool is a command-line program, and FrontierStack installs it from its GitHub releases.

For day-to-day work with Apple containers we recommend Davit, an independent macOS app that puts a proper graphical front-end on that same container command — browsing containers and images, starting and stopping them and following logs, without having to remember subcommands. The Apple Containers section installs it for you through its Homebrew cask and opens it afterwards. Davit needs Apple silicon and macOS 15 or newer.

8.6Remote Tools — per-node diagnostics

Fleet & Remote ▸ Remote Tools is a suite of SSH-driven diagnostics, distilled from real fleet-debugging work. Choose the target first — a pinned server, or Other (IP / host)… for an ad-hoc address that isn't a saved server (its sudo password persists in the Keychain too) — then the tool and its parameters. Read-only checks need no root; ones that read protected logs or config use the saved sudo password through the helper, and a few are marked mutating.

Some tools work across several selected nodes at once — File Diff, Healthcheck, TLS Expiry and Serving Path Diagnosis (who's up, which public IPs each node binds, per-process CPU saturation and stopped services, cross-checked against every pinned Cloudflare zone's origin IP) are fleet-wide by design — which is exactly how you confirm every web node is serving the same content with a valid certificate. The bottom of the pane also offers safe over-SSH editing of /etc/hosts (root, through the helper) and the SSH user's ~/.ssh/known_hosts, each backed up to .fsbak first.

8.7Recovering a wedged server — and a safe power reset without SSH

A server can stop answering SSH while its services keep running — overloaded, not down. FrontierStack shows this: when SSH is unreachable but a service port still answers (say MySQL on 3306), the server's dot turns orange, not red, and its pane reads "SSH is wedged, but the server is still serving" and lists what's answering, with the database's version banner. The machine is alive — only its management channel is stuck — so don't assume it's dead or blindly cut the power.

Try a normal Reboot first. After Reboot, the dot flashes while FrontierStack waits out a grace period and then polls, refreshing the instant the host returns — no need to keep pressing Refresh.

Make a power reset safe — without SSH. When a database is still answering, the pane shows a red-outlined EMERGENCY box, Prepare databases for a safe power reset. Each step runs over the database's own connection (no SSH), using the credentials saved in Database Health, top to bottom: Stop accepting writes (reads still work, reversible), Quiesce & flush to disk, then Clean-shutdown. After a clean shutdown a hard power-cycle is safe, because nothing dirty is left in memory to corrupt. Coverage differs by engine — MySQL, Redis and MongoDB can be cleanly stopped over their protocol; PostgreSQL can be quiesced and flushed but not stopped over SQL, so you flush then power-cycle. The clean-shutdown button is red and confirms first.

Power-cycle, then bring it back. The hardware power controls (SwitchBot plug, smart powerboard/PDU, KVM) each offer Shut Down Databases First in their confirmation, so you can flush and stop the databases before cutting power. And if the shutdown relieved the pressure and SSH recovers, a Start button starts the database again over SSH — so the ideal path is often: clean-shutdown the runaway database, let the box recover, and Start it, with no power-cycle at all.

8.8The Host Monitor (remote agent)

SSH diagnostics run on demand. For continuous visibility, install the Host Monitor — a tiny, read-only Go helper (fsagent) that lives on the server and reports its own health, with no per-cycle SSH. From a linked host's pane, choose to install it (or tick the box in Link a Server); over the existing key the app pushes the right binary for the host's OS and architecture, sets up the platform service (systemd, launchd or BSD rc.d), and pins its TLS certificate. The AI tool install_monitor does the same on request.

Once enrolled, the monitor streams live metrics: CPU, memory, per-mount disk, network interfaces up, detected services, firewall and fail2ban state — and on GPU hosts, per-GPU temperature and utilisation, so a mining or ML rig surfaces thermals. list_monitors reports the fleet's helpers, their versions and latest metrics. Crucially, the monitor keeps watching and can alert even when the Mac app is offline, notifying directly through its own channels and replaying anything it buffered when the app returns. Logs windows prefer the monitor too — it runs as root on the server, so it reads privileged logs without needing the sudo password at all.

An enrolled host's pane also keeps a Behavior & History chart — CPU, memory, disk and temperature at five-minute resolution for up to 30 days, against a learned baseline that flags unusual behaviour. Temperature uses its own degree-marked scale, so it remains readable beside percentage-based resource use. Vertical lines place incidents on the same timeline: a solid red line is a server reboot (derived from the reported uptime), a dashed orange line is a watchdog issue — a forced service restart, a database-corruption warning or a reboot escalation. If the OS crash reporter starts using CPU (a process crashing repeatedly), an orange Crashes curve joins the chart, so "MySQL was force-restarted twice last night and something was crash-looping" is visible at a glance.

The monitor is read-only by default. Turning on Allow actions in its Host Monitor pane unlocks a small, fixed set of control verbs — never arbitrary shell — driven by the gated monitor_action tool: restart/reload/start/stop an allowlisted service, flush DNS, reload the firewall or fail2ban, or reboot. Each action is logged on the server. Targets cover Linux (amd64/arm64/arm — covering every Raspberry Pi), macOS (including legacy Intel builds back to OS X 10.11 El Capitan), FreeBSD (pfSense/OPNsense/TrueNAS) and Windows.

Keeping a monitor healthy over time is handled for you. Rotate monitor credential replaces its bearer credential in place: the new secret is generated on the Mac, sent over your approved FS1 signing key, and activated on the server without ever being shown or handed to an AI. With Allow self-update enabled, pushing a newer build is safe by construction — the candidate binary's release signature is verified, it must pass a compatibility self-test before it is given root, and the previous binary is kept as a rollback; if the new one fails to answer its health check, FrontierStack restores the old one automatically. Pull-mode updates fetch the binary through a short-lived, single-use grant rather than a durable token. When a monitor is verifying FS1-signed requests, its pane shows a FS1 signed badge.

8.9Cloud Servers, Server Clone & Remote Apache

Alongside the compute panes, AWS ▸ DynamoDB lists the tables in the selected region with their status, item count, size and partition/sort key. It leans on the two things that actually cost you: the capacity mode capsule separates provisioned tables — which bill for their read and write units continuously, whether or not anything touches them — from on-demand tables that bill per request; and a no PITR flag marks any table without point-in-time recovery, which is off by default on every new table and is the only way to rewind after a bad write. Point-in-time recovery can be switched on or off from each row's menu. DynamoDB has no bulk describe call, so each table is queried individually and the list is capped at 40 per region.

Fleet & Remote ▸ Cloud Servers rolls up one inventory across every cloud provider that has a configured API token — DigitalOcean, Vultr, Linode, Hetzner, Sakura, Contabo — plus AWS EC2, Lightsail and RDS. It is a read-only roll-up (power control stays in each provider's own pane). Each running instance with an IP offers a Services button to discover what's listening, and a + Helper button that links the instance over SSH and installs the monitor in one move — just set the right username and key in the sheet.

Server Clone is a guided wizard that stands a fleet server up to match this Mac: it installs the detected Homebrew stack, copies configs and site files to their original paths, pushes your domain configs and reloads the web server, and can clone MySQL databases (local mysqldump piped into mysql on the target over SSH). Every step runs over key-based SSH and is safe to re-run; existing data isn't deleted.

When a single site is ready to go live, the Promote to Production push (from a domain's context menu) sends its vhost config to the same path it uses locally, optionally copies the document root and database, points DNS at the target via Cloudflare, and can issue a real Let's Encrypt certificate with certbot — files, database, vhost, DNS and HTTPS in one push.

You can also manage a remote server's Apache directly. The Apache pane gains a host selector (This Mac / each linked server) when any remote host exists; pick a server and FrontierStack discovers its Apache over SSH — version, config layout, and every active vhost with its real log paths — and lets you edit vhosts, modules, MIME types, ports and WebDAV, with each change validated (httpd -t) and gracefully reloaded before it sticks, rolling back if the config is invalid. It even understands the legacy macOS Server.app Apache tree. From the Sites list, Push to Server… renders a local site's vhost onto a monitor-linked server with its document root swapped in. Chapter 7 covers the local Apache and Sites workflow these mirror.

8.10Screen sharing to a host

Each server's pane offers whatever remote-access method its probe detected — Apple Screen Sharing / VNC for a Mac, RDP for Windows, and AnyDesk, TeamViewer, RustDesk or NoMachine when their clients are present. When Apple Remote Desktop is installed on this Mac it registers the vnc:// handler and captures the click, so the pane offers a separate Screen Sharing (macOS) action that always opens Apple's built-in Screen Sharing client instead. If the host is reachable at more than one address — a LAN IP and a VPN or Tailscale address, say — that action becomes a menu so you pick which network to connect over; each choice dials the numeric IP directly, so it still works when the host's name isn't resolving (mDNS, split-horizon DNS, or a VPN quirk). A matching “— by IP” button appears for VNC and RDP whenever the pane would otherwise use a name that might not resolve.

8.11KVM-over-IP: console and power, lights-out

SSH and Screen Sharing need the machine to be up and on the network. When it isn't — a kernel panic, a BIOS/firmware screen, a network stack that never came up — you need out-of-band access: a KVM-over-IP appliance that captures the real HDMI output and injects USB keyboard/mouse, independent of the operating system. The Remote KVM pane registers as many of these as you own — PiKVM, JetKVM, TinyPilot, NanoKVM, GL.iNet Comet, or any generic unit — each pinnable, each one click from its web console down to the BIOS.

Units with power control close the loop. A PiKVM with an ATX board, a network PDU, or GL.iNet's Comet Pro (GL-RM10) — which is a KVM and a smart power plug in one device — can switch mains power, so you can hard power-cycle a truly frozen box. Link such a unit as a server's power source in its Power section (beside SwitchBot, UPS and PDU commands) for On/Off/Cycle. The AI Administrator can drive it too: list_kvms, kvm_power, and server_power — the last reaches a host's linked plug/PDU/KVM to restart a hung server that won't answer reboot_host.

8.12Boot Media: installing an operating system over the network

Reinstalling a server used to mean a trip to the rack with a USB stick. The Boot Media pane (Fleet & Remote) replaces the stick: you keep installer images in one library on this Mac, and FrontierStack presents the one you choose to the target machine as a virtual CD — through the server's management controller, a PiKVM, a Proxmox VE virtual machine's CD drive, or a network boot menu. Macs are handled differently, because Apple no longer lets them boot that way; see Macs below.

8.17.6The image library

Add ISO or Disk Image… records a local file; the file stays where it is and nothing is copied. Add Image URL… records an image that already lives on a web or file server (http, https, nfs or cifs) — a remote URL is handed straight to the target, so this Mac never has to carry the bytes. Compute SHA-256 records the file's checksum so you can compare it with the vendor's published one before installing anything from it. Each entry can be renamed, shown in Finder, removed from the library, or its served address copied with Copy Image URL. An entry whose file is no longer at its saved location is flagged as missing.

8.17.7The built-in media server

A management controller mounts an ISO by reading it over HTTP, piece by piece, for as long as the install runs. The pane's Media server serves the library's local images for exactly that: it supports byte-range requests and keep-alive, which virtual CDs need, and shows a log of recent requests and the bytes served per image, so you can see a controller actually reading. It starts automatically when a target needs a local image, or you can press Start Serving yourself.

8.17.8Server management controllers (Redfish)

Most rack servers carry a baseboard management controller that can present an image as a virtual CD. FrontierStack drives it through the standard DMTF Redfish API: Dell iDRAC 8 and 9, HPE iLO 4, 5 and 6, Lenovo XClarity Controller (XCC), Supermicro X12 and newer, and any other controller that implements standard Redfish virtual media.

1. Add Controller and enter its address, port, username and password. The password is kept in the Keychain and sent only to the controller. Optionally link the controller to a fleet server so the two are shown together. Use an account with the Virtual Media and Control privileges.
2. Read Controller discovers what it manages: each system with its model and power state, and each virtual CD slot with whatever is mounted in it now.
3. Choose the System, the Virtual CD and the Image. Leave Boot from it once on to boot the CD a single time, after which the server returns to its normal boot order.
4. Under Then, choose Don't restart, Graceful restart or Force restart, and press Mount (or Mount and Restart, which asks for confirmation first).
5. When the install is done, Eject the virtual CD.

8.17.9PiKVM virtual media

A PiKVM can emulate a USB drive for the machine it is plugged into. Boot Media uses PiKVM's documented /api/msd interface, with the same PiKVM API account as its ATX power control (see KVM-over-IP). First copy an image to the PiKVM's own storage: a local file is streamed up with a progress bar, or the PiKVM downloads a remote URL itself. Free space is checked before the copy starts. Then connect a stored image As CD-ROM (for an ISO) or As Flash (for a raw .img), pick it in the machine's boot menu or use Power Cycle… (a hard ATX cycle, with confirmation), and open the console to follow the install. Disconnect Drive and delete tidy up afterwards.

8.17.10Proxmox VE virtual machines

For a virtual machine on Proxmox VE (connected as described in Proxmox VE below), choose the Node, the Virtual machine and the ISO storage, then the Source. Image from the library has Proxmox download the image into ISO storage itself (its download-url call), so a local image is fetched from this Mac's media server; ISO already on Proxmox uses one that is there. FrontierStack attaches the ISO to the VM's CD drive and can put the CD first in the boot order — the original order is remembered and restored when you eject. Finally choose to leave the VM as it is, start it, or reset it (a hard reset, which asks for confirmation).

The API token needs Datastore.AllocateTemplate and Sys.AccessNetwork for the download, and VM.Config.CDROM, VM.Config.Options and VM.PowerMgmt on the VM. The pane lists these beside the controls.

8.17.11Network boot (PXE / iPXE)

Machines with no controller and no KVM can still boot over the network. Turn on Serve an iPXE boot menu from this Mac and the media server also publishes an iPXE menu that SAN-boots any library ISO over HTTP, chains to netboot.xyz for its catalogue of installers, and offers an iPXE shell and boot from local disk. Download iPXE Boot Loaders fetches the official loaders from boot.ipxe.org (ipxe.efi, undionly.kpxe and the arm64 ipxe.efi) so UEFI HTTP Boot clients can load iPXE straight from this Mac.

What remains is telling your DHCP server where to send booting machines. Pick your DHCP server and press Copy Settings for a ready-made snippet:

8.17.12Other KVM-over-IP units

JetKVM, GL.iNet Comet, NanoKVM, TinyPilot, Raritan, ATEN, Avocent, Lantronix and Adder units have no stable public API for virtual media, so FrontierStack does not pretend to drive it. Instead Copy URL starts serving and copies an image address the KVM can reach, and the pane shows where to paste it in that vendor's own console.

8.17.13Macs

A Mac cannot boot an installer ISO, and network boot is gone: Apple silicon has none, and Intel NetBoot lost its server in macOS Server 5.7 and is refused by T2 Macs at Full Security. So for Macs, Boot Media installs macOS the way Apple supports — by downloading Apple's full installer on the Mac itself over SSH and running it. Every remote Mac in the fleet gets a card (add Macs under Remote Servers first):

• Refresh reads its macOS version, whether it is Apple silicon, Intel or Intel with T2, the model, free space, the installers already present, and whether Content Caching is on.
• List asks Apple which full installers are available (softwareupdate --list-full-installers); Download on the Mac fetches one in the background (--fetch-full-installer) with progress.
• Install… runs startosinstall in one of two modes: Upgrade / reinstall (keeps data) or Erase and install. On Apple silicon only a volume owner may start an install, so you enter an administrator user and their password; the password is passed to startosinstall on standard input and never stored.
• Turn On Content Caching (on this Mac or any fleet Mac) keeps a copy of Apple's updates and installers on the LAN, so every other Mac downloads them from there rather than from Apple.
• For an Intel Mac with a linked KVM, Internet Recovery… restarts it into Apple's own network recovery, after confirmation. Recovery has no Screen Sharing or SSH, which is why a KVM is required to drive it.

8.17.14From the AI Administrator

The AI Administrator and MCP clients reach Boot Media through the existing kvm tool: media_list (read-only) reports the library, the media server's state, each controller's power and mounted image, and each PiKVM's drive; media_attach mounts an image on a target — a controller or PiKVM by name, or proxmox:<vmid> — and with boot=true also restarts into it; media_eject removes it. Attaching, ejecting and restarting need Allow changes and always ask you to confirm (Chapter 13).

8.13Proxmox VE: live cluster status and guest power

A Proxmox VE host is a server full of servers, and SSH to the node alone does not tell you much about its guests. The Proxmox VE service page (Containers category; see Chapter 6) therefore talks to Proxmox's own API. Add Connection and enter a cluster or single node's address with an API token — the token ID in user@realm!name form and its secret, which is kept in the Keychain and sent only in the Authorization header. Proxmox's self-signed certificate is accepted only on a private address. A token with the PVEAuditor role is enough for status; power control and boot media need the extra permissions listed above.

Once connected, the page shows the cluster name, Proxmox version and quorum; for each node its CPU, memory, root disk and uptime; every VM and container with its state; and a usage bar for each storage. Each guest can be started, shut down or rebooted, and — after confirmation — hard-stopped or reset. Show in Server Activity and Boot an ISO… jump to the other two places Proxmox appears.

In the Server Activity window (Chapter 11) every node is a tile in the All Servers, Cluster and Everything layouts, with CPU, memory, disk and uptime sparklines and a line such as “5/7 VMs · 2/3 containers running”. A node's detail shows its KPIs, a CPU and memory chart, the guest list with the same power controls, its storage and the cluster facts, plus Open Web UI, Refresh and Boot an ISO….

Alerts watches each connection in the background, refreshing about every five minutes: API reachability, each node's online state, cluster quorum, and any storage more than 90% full. The AI Administrator has the same view through the kvm tool's proxmox_status action (read-only) and can change a guest's power with proxmox_power, which always asks for confirmation.

8.14Old Macs, Raspberry Pis & Windows hosts

Part of the point of a fleet is keeping older or odd hardware useful. A vintage Xserve or Mac mini still running macOS Server links like any other host; the Remote Apache discovery understands Server.app's own Apache tree and its internal ports, so its websites show up and can be edited, and the legacy Intel builds of the monitor run as far back as OS X 10.11 El Capitan. A shelf of Raspberry Pis links as ordinary Linux boxes — the monitor's arm build covers every Pi including the Zero — so you watch their CPU, disk and services right alongside everything else.

Windows hosts join over Microsoft's OpenSSH server: link them like a Linux box for SSH diagnostics, and install the monitor as a native Windows Service (because Windows services don't reliably inherit machine environment, its config is read from a file beside the executable). Windows monitor installs are done manually with the supplied PowerShell installer from the Host Monitor pane, rather than auto-pushed.

For interactive control beyond diagnostics, the catalog also carries the remote-access tools — RustDesk, MeshCentral, Apache Guacamole, Windows Remote Desktop and WinRM — but those are services you run, not the SSH fleet itself. The fleet's strength is uniform, scriptable, low-overhead management of everything from one window — and, with Chapter 13's run_script targeting any node by name, an AI that can diagnose and fix a remote server two steps at a time: a read-only test, then a minimal fix, re-run to confirm.

8.15OpenCore Legacy Patcher Macs: is it safe to update?

Some of those older Intel Macs will be running a macOS newer than Apple ever shipped for them, courtesy of OpenCore Legacy Patcher (OCLP). That changes what a reboot means. An ordinary server Mac boots power → macOS → FrontierStack agent; an OCLP Mac boots power → firmware → EFI/OpenCore → macOS → OCLP root patches → FrontierStack. Every extra link is a place where an unattended boot can stop: a macOS update replaces the sealed system volume and takes the root patches with it (Wi-Fi, graphics acceleration and Bluetooth vanish until they are re-applied), a major upgrade needs a matching OCLP release first, and if the firmware's startup entry ever stops pointing at OpenCore the machine sits at a boot picker until someone holds Option and chooses “EFI Boot” — considerably more troublesome when that Mac is in another building.

The OpenCore Patcher pane (Fleet & Remote) exists so you know this before you press Update. Pick This Mac or a linked Mac and it runs a read-only probe — the OCLP app version, OpenCore's NVRAM stamp (only present when the Mac actually booted through OpenCore), the root-patch receipt, bless --getBoot, SIP, Software Update settings, the real model behind OpenCore's spoofed one — and turns it into a Remote boot safety list: firmware boot entry → OpenCore, default boot volume set, FileVault's effect on unattended reboot, root patches present and current, OCLP release supports the installed macOS (checked against the newest GitHub release), pending macOS update, automatic macOS installs off, and an EFI/OpenCore backup. Above it sits one verdict: Safe to update macOS, Update with caution, or Not safe, with the reasons.

The pane deliberately does not administer OCLP — building OpenCore and applying root patches stay in OCLP's own app. It offers three fixed, reversible admin actions: turn off automatic macOS installs (so System Settings never updates an OCLP Mac unattended), back up EFI (an archive of the EFI/OC folder kept on that Mac), and re-bless OpenCore (the same bless --setBoot OCLP's “Install to disk” runs, refused unless OpenCore.efi is really there). The fleet status probe also notices OCLP on every pinned Mac: the host row and the Server Activity window show it, and Alerts raises a Security item when root patches are missing or the boot entry bypasses OpenCore.

8.16Migration wizards: moving a stack onto a new device

Retiring an old server rarely means "reinstall everything by hand." FrontierStack ships guided migration wizards that lift a stack off a legacy machine and stand it up on a destination you choose — this Mac, another Mac, or a Linux box. The source is only ever read; everything is written to the target.

The Migrate Setups pane handles a MAMP, XAMPP or Apple Server.app web stack. It auto-detects the source, then lets you tick exactly what to carry: the Homebrew tools, web files, MySQL databases, the sites (vhosts), MIME overrides, Apache modules, PHP settings, WordPress wp-config.php fix-ups and Git repositories. A Set up on picker chooses the destination: leave it on This Mac for the full in-app migration, or pick a linked host to install the stack on that new device over SSH, copying the web files (rsync) and databases (dump over SSH) across — with a Linux toggle to use apt/dnf instead of Homebrew.

The pane's Servers section also has Import from a Repo…: point it at a folder or git repo that holds an SSH config, an Ansible inventory or .env files, and it adds the servers to your fleet and the credentials to Script Secrets or the matching service, after you review them. FrontierStack AI can read other layouts without ever seeing a value (Ch 13).

The Apple Server Migration pane is a one-click wizard for a whole Server.app machine. Point it at the source (this Mac or a remote one) and it inventories every service with serveradmin — Websites, Mail, Calendar and Contacts, Messages (XMPP), VPN, DNS, DHCP, NetInstall, Open Directory, File Sharing, Time Machine, Profile Manager and more — and anything else it finds running, such as a git server, databases, Docker or a standalone Nginx. Each service shows a status badge and a modern equivalent; where there's more than one sensible replacement (Calendar → Radicale / SOGo / Baïkal, VPN → WireGuard / strongSwan, DHCP → dnsmasq / Kea) you choose which one. Pick a target machine and OS, and the wizard installs the equivalents and prints a precise carry-over checklist. Services with dedicated importers — Websites (full vhost + file copy) and Open Directory (users and groups) — hand off to their own panes; a detected git server hands off to the Git Server migration.

8.17The Git Server: Gitea & repository migration

The Git Server pane stands up a self-hosted Gitea (behind Caddy for automatic HTTPS) on any target — this Mac, a linked server, a NAS, a Docker host or a Linux box — detecting the platform and installing the right way. Once it's running, connect with an access token for a live monitor: version, repository count and backup-staleness alerting when a mirror falls behind its source.

The same pane migrates or mirrors another Git server into Gitea. Point it at on-disk bare repos — the legacy macOS app Simple Git Server, Xcode Server, Gitolite, a plain git-daemon, or any folder — or at a running remote server via any git://, https:// or ssh:// clone base (enumerate the repo names over SSH, or paste them). Scan lists the repositories; Migrate mirror-clones each one with full history, every branch and tag, and pushes it into Gitea, creating the destination repo through the API. The copy runs on this Mac.

A Mac that runs services lives inside a network, and that network is where most real-world trouble starts: a router whose WAN link flapped, a forgotten device on the wrong subnet, a port you opened months ago and never closed. FrontierStack treats the network and its perimeter — the boundary between your LAN and the internet — as first-class objects. It reads your router directly, scans the LAN to build an inventory, draws a data-flow map, and gives you several disciplined ways to expose a service to the outside.

This chapter covers the network around your servers. For linking the servers themselves over SSH see Chapter 8; for the host firewall, fail2ban and the security audit see Chapter 10; and for Cloudflare DNS and TLS see Chapter 7.

9.1Routers & firewalls you can read and drive

FrontierStack talks to network gear through its own management API where one exists, and over SSH where it does not. The two tightest integrations are OPNsense (its full REST API) and Cloudflare (covered in Chapter 7); a wider set of routers and firewalls report live status. Add a device in the Router & Network pane with its address, vendor and API key, and the AI Administrator's router_info tool can then read its version and model, uptime, CPU and memory, WAN links and gateways (up or down), interfaces and client count — plus the raw API JSON for any field FrontierStack does not map. It is read-only: it queries the device's own API, never SSH.

For OPNsense and pfSense, an API key unlocks a continuous firewall monitor (the toggle in the pinned device's pane): every Alerts sweep polls the firewall itself for gateway state, interface carrier and service liveness — so a WAN line that dies while a multi-WAN router silently fails over (servers browse fine, inbound to your sites is dead) raises an alert naming the gateway and the port that lost carrier, instead of an unexplained sea of red site dots. Nothing is installed on the router: OPNsense's REST API is built in, and pfSense needs only its REST API v2 package. The same pane can also join an OPNsense router to your tailnet: sign in to Tailscale on your Mac (Google accounts work), mint a pre-auth key, paste it in the device pane's Tailscale section — FrontierStack installs the os-tailscale plugin if needed, saves the key and login server (Headscale too), and restarts the service over the API, no browser login on the router required. The tailnet address is then remembered as a fallback: when the LAN address stops answering (off-site, VPN route down, LAN leg dead), Check Status, the monitor and certificate renewal retry over Tailscale automatically and say so, and the monitor raises a separate "LAN address" alert so a routing fault is not mistaken for a dead router.

Attack and failure signals. The same sweep that watches gateways also watches for trouble on the router itself, and a router in distress turns orange with a warning triangle in the sidebar — hover for the reason. On OPNsense with the Intrusion Detection plugin enabled, FrontierStack reads its recent Suricata alerts over the same API and shows the count and top signature (an attempted attack surfaced without opening the firewall UI; pfSense's REST API does not expose IDS uniformly, so this is OPNsense-only for now). Across every monitored router — OPNsense, pfSense, OpenWrt and the rest — each sweep also flags an unexpected reboot (uptime dropped sharply: a crash, a power event, or an attack), a brute-force spike on the router's admin/SSH (repeated failed logins, with the busiest source IP named from the router's own log), resource stress (memory or load dangerously high — a DoS, a runaway or compromised process), and an available firmware update (outdated firmware means known holes). Each raises an alert; signals a given platform cannot report are simply skipped, never a false all-clear. OPNsense and OpenWrt report the most; pfSense's API is more limited.

Certificate expiry. The same sweep reads the firewall's trust store — every CA and certificate a service uses — and raises an alert a month before one expires, and again once it has. This is the failure nobody plans for: an OpenVPN server certificate issued on OPNsense's 397-day default quietly locks every remote user out a year later, and the Web GUI's own HTTPS certificate lapsing turns the admin page into a browser warning. The device pane lists them soonest-first with a coloured dot, and a Renew… button reissues a certificate in place through the router's API: same private key, subject and CA, a lifetime you choose (up to ten years), and optional restarts of the OpenVPN servers and the Web GUI so they load it. Because the key and subject are unchanged, existing VPN client profiles keep working — nothing to re-export. On pfSense the REST API's renew action does the equivalent and restarts dependent services itself, and because its API reports no expiry for certificate authorities FrontierStack reads that date out of the CA certificate itself, so a pfSense CA warns like any other. CAs cannot be renewed through either API; an expiring CA is announced early precisely because replacing it means re-signing certificates and redistributing client profiles. The OpenVPN service pane shows the same router certificates next to the CA and client certificate embedded in every .ovpn profile on the Mac (OpenVPN Connect, Tunnelblick, the last file used), so client and server expiry sit side by side; its Plan & Cost card also notes that OpenVPN itself is free and what Access Server and CloudConnexa charge.

Driving and diagnosing a router. The AI Administrator can now do more than read: reboot_router restarts an appliance the same way it reboots a server (OPNsense/pfSense via API, OpenWrt over SSH), gated behind "Allow changes"; and when a task is genuinely better done in the router's own console, the assistant offers to open its Web UI with open_web_ui, resolving the address from the device pane rather than guessing. FrontierStack itself deliberately does not edit these appliances' firewall rules — OPNsense/pfSense/OpenWrt manage rules through their own config system, so the pane and the assistant point you at the native firewall page instead (right-click a router ▸ Open firewall rules… deep-links it). Two pane conveniences round this out: a Diagnostics button runs an API-free reachability check (ping, the common admin ports 80/443/8443/53, reverse DNS, gateway) so you can triage a router even without an API key; and for a router or firewall, Discover Services offers to open the Web UI rather than port-scanning it (a scan of your own perimeter device is rarely what you want). If SSH to an OPNsense or pfSense box is refused, SSH is either disabled or — more often — only allowed on certain interfaces (commonly the LAN, not the WAN): reaching it over the LAN, e.g. through a VPN, usually works, while from outside it is typically blocked. Enable SSH and its listening interfaces in the web UI (System ▸ Settings ▸ Administration ▸ Secure Shell on OPNsense). The SSH button itself is only hidden for consumer gateways that have no admin shell at all (NTT, some TP-Link/FRITZ!Box), where the Web UI is the only way in.

9.2Firewall vitals, graphs and power

A pinned OPNsense, pfSense or OpenWrt firewall with monitoring switched on reports its own vitals through its API, and its pane now graphs them: CPU and memory on one 0–100 chart, load average, and temperature. The samples come from the monitoring poll that was already running, so the graphs cost no extra API calls and fill in as the Alerts sweep proceeds, covering roughly the last six hours of the session.

What each platform gives differs, and the pane shows only what is real: pfSense reports an instantaneous CPU percentage, while OPNsense reports load average instead. Temperature depends on the hardware exposing a sensor FreeBSD can read — many virtualised and ARM installs have none, so a missing figure means "no sensor", not a fault.

Any pinned device can also have a smart plug linked to it, exactly as servers do: On, Off, Power-cycle, and a live wattage reading where the plug meters it. This matters most for a firewall, because it is the one box you can never reach over SSH when it wedges — the network you would reach it over is the one it serves. Neither OPNsense nor pfSense reports its own power draw (FreeBSD exposes thermal sensors, not watts), so a metered plug is the only real power figure available for one. Power-cycling asks for confirmation and warns that every connection through the firewall drops; try the API reboot first.

9.3Device Discovery: an inventory of your LAN

Open Device Discovery and press Find Monitors (or pick a subnet first). FrontierStack sweeps the chosen /24 using every method available at once, so routers, access points, switches, NAS boxes (Synology, QNAP, ZimaCube/ZimaOS…), printers, cameras and other servers all surface:

• Ping / ARP — an ICMP sweep, with ARP/MAC giving each host's vendor; turn on TCP Probe to find hosts that filter ICMP.
• Bonjour (mDNS) and SSDP / UPnP — advertised services and their friendly names.
• SNMP and LLDP / CDP — add model, port and neighbour details when net-snmp and lldpd are installed (buttons in the pane install them).
• Windows service ports — a machine that filters ICMP is still found by probing its distinctive ports (RDP, WinRM, SMB and friends), so Windows PCs no longer hide from the sweep.

The scan also notes how each host can be reached. An AnyDesk badge appears when AnyDesk is running locally or answering on its default port 7070, and a Tailscale badge — green when the peer is online — is built from this Mac's own tailscale status, matching mesh peers to discovered devices (only endpoints, hostnames and OS are kept; login names are never retained). On a directly-connected LAN, the Macs and devices macOS already knows through Bonjour appear before the slower IP sweep, so the list fills in quickly. A device's detail view carries matching AnyDesk and Tailscale rows with an Open app shortcut.

The AI Administrator's discover_devices tool runs the same scan and auto-pins the devices whose type it can identify confidently. Anything ambiguous is listed back rather than guessed at, so the assistant can ask you what it is and then pin it with pin_device. A pinned (monitored) device appears in its type's sidebar section; double-click it to open its pane, or use Open Web UI, Discover Services, Reclassify or Remove from its row. If you already know an address, the Add a device by IP field probes and pins it directly — no full scan needed.

9.4Cameras from every maker

The Cameras pane is one status board for every camera FrontierStack knows about, whether or not it can show a picture. It gathers cameras found by Device Discovery (pinned, and found but not yet pinned), AV Feeds streams, SwitchBot cameras, Smart Life cameras and UniFi Protect cameras. With dozens of cameras, the counts at the top and the Offline filter are the quick answer: offline cameras sort first, and a stream whose address matches a pinned camera is shown on that camera's tile rather than twice. A Protect camera with the same MAC address as a pinned camera is shown on that camera's tile. The bell on each tile switches its offline alert, and Alert on All covers every camera that can be checked at once. Alerts go through the Alerts pane, so a contacts preset can page the technician for the site.

A camera counts as alive if it answers on RTSP (port 554), its web port (80) or ONVIF (2020). Cloud-only cameras such as Ring, Nest, Blink and Arlo show no status, because only their own app can reach them.

Tapo cameras from anywhere (unofficial). In Services ▸ Cameras ▸ Tapo Cameras, sign in with your TP-Link ID to see each Tapo camera's online / offline state even when the Mac is away from home, with offline alerts through Alerts. FrontierStack signs in the way the Tapo Android app does, because TP-Link offers no official API — so it can break when TP-Link changes its app, and using it may be against TP-Link's terms. Only status is read. Your password is never stored, a camera counts as offline only after two checks in a row, and if TP-Link's cloud can't be reached the camera shows Status unavailable, never offline. Pinned Tapo cameras keep a green dot off-LAN while the cloud says they are online; other Tapo devices and, with a second sign-in, Kasa devices can be watched too.

SD cards. For Tapo, Hikvision/Annke, Dahua/Amcrest/Lorex, Reolink and Axis cameras, each tile also shows the memory card as the camera itself reports it: SD ✓ 42% used, No SD card, Unformatted, SD card error, or SD — when it isn't known (hover for the reason). FrontierStack asks the camera's own local API, never a cloud, and only while the Mac is on the camera's network; away from it, the last result stays with its time. Checks run every 30 minutes, one camera at a time and at most once per 10 minutes per camera. Non-Tapo cameras use the login from their AV Feeds stream or one you enter in the camera's device pane. Tapo cameras need admin and your TP-Link account password, entered once under Tapo Cameras ▸ Local camera access; it stays in the Keychain and is never sent to TP-Link's cloud. If a camera refuses a login, FrontierStack stops asking it until you fix the login or press Retry, because cameras lock accounts after repeated failures. A camera that can't be reached or signed in to is never reported as having no card. SD alerts are opt-in; nearly full alerts are off by default because most cameras loop-record and are always close to full. eufy, WTW and Eseecloud cameras have no local storage API.

What each make needs:

9.14.1WTW cameras and recorders

Older IP cameras. WTW's own 2018 IP camera manual gives rtsp://ip:554/live/0/main for the main stream and /live/0/sub for the sub stream. Port 554 is the default and can be changed. RTSP is turned on in the camera's web network settings. Current PoE/IP models and NV4-series recorders list RTSP and ONVIF in their specifications. If the path above doesn't connect, add the camera over ONVIF in an NVR app to find its URL.

EAGLE Wi-Fi line. These have no RTSP and no ONVIF. WTW's support site says so for one camera, and the recorder specification lists only TCP/IP, DHCP and P2P. For these, the most you can do is check that the recorder answers on its web port: pin it in Device Discovery as WTW Camera / NVR and turn on its offline alert.

Default passwords. NV4 recorders use 00000000, which becomes wtwjapan after a factory reset. Older cameras use admin with a blank password, or admin/admin. Change them before the device goes on your network.

9.14.2Smart-home clouds

Smart Life (Tuya) devices are read through Tuya's official Cloud API. Create a Cloud project at iot.tuya.com in your account's data center (Japanese accounts use Western America), link your Smart Life account with Devices ▸ Link Tuya App Account, and paste the project's Access ID and Secret into the Smart Life pane. You then see every device's online state and plug power, can switch plugs and lights, and can have any device alert when it goes offline. The free trial allows about 26,000 calls a month and must be extended every few months, so FrontierStack checks every 10 minutes.

Minut sensors report noise, occupancy, temperature and humidity in rentals. The Minut pane alerts when a sensor goes offline, when its battery runs low, and when a home has a noise disturbance in progress. Minut opens its API only to accounts it has approved; its help article ties this to the Enterprise plan.

SmartThings, Govee, LIFX, Sensibo and Nuki each have their own pane that lists the account's devices with a status dot: green online, red offline, grey when the cloud didn't say. Turn on the bell next to a device, or Alert on all, to get an alert when it goes offline. Govee, LIFX, Sensibo and Nuki need only an API key or token from the vendor's app or website. For SmartThings, create your own OAuth app once with the SmartThings CLI so sign-in keeps working. A personal access token also works, but it expires after 24 hours. If a key is rejected or a sign-in expires, you get one account alert. If a cloud can't be reached, its devices are left unknown. Neither case is reported as devices going offline. Nuki locks are worth watching in rentals: a lock that has lost its connection can't be opened remotely for guests.

9.5The Data Map

The Data Map pane draws a per-location data-flow diagram: where your data lives and how it moves across the devices and services at one site. FrontierStack serialises the location's inventory — the discovered devices, their roles, and (optionally) scanned ports — scrubs it of secrets, and hands it to your subscription Claude through the local claude CLI (not the metered API the in-app harness uses). The reply comes back as a Mermaid flowchart plus a short narrative, rendered offline in the pane; the last diagram for each location is kept, and you can save it to your Obsidian vault as a runbook. Locations themselves are explained in Chapter 8.

9.6Opening a port: UPnP and NAT-PMP/PCP

To reach a service from the internet the classic way, a port on the router has to forward to your Mac. Rather than make you log into the router by hand, FrontierStack can ask the router for a mapping using the standard protocols it advertises:

• UPnP IGD (via miniupnpc) — the common consumer-router method.
• NAT-PMP / PCP (via libnatpmp) — Apple's and the modern equivalent.
• OPNsense — a perimeter rule and port-forward through its API directly.

These tools are installed on demand the first time you use them. A mapping made for a temporary session (see Debug Share) is torn down automatically when the session ends.

9.7Dynamic DNS: following a changing IP

Home and small-office connections rarely have a static IP, so a hostname you point at today's address goes stale tomorrow. The Dynamic DNS pane keeps a hostname tracking your current public IP. Add an entry with a Name, a Hostname (for example myhost.duckdns.org) and the account data for your provider; press Update Now to publish immediately, or turn on Update automatically. You choose whether the updater runs only while FrontierStack is running or permanently as a system service, so the record stays current even when the app is closed. Cloudflare users get a tighter path: a Cloudflare DDNS A record that follows your public IP, driven by the same Cloudflare integration as Chapter 7; a generic interval-based updater covers other providers via an update URL.

9.8Tunnels and mesh: reaching in without opening up

The better way to reach a service from outside is to skip inbound ports entirely. A tunnel makes an outbound connection that an outside endpoint rides back in on, traversing NAT with nothing forwarded:

• Cloudflare Tunnel — a Quick Tunnel gives you a public *.trycloudflare.com URL with no account, or a named tunnel for a permanent hostname.
• Tailscale — Serve keeps a service private inside your tailnet; Funnel publishes it to the internet through your Tailscale node.

For ongoing connectivity between machines, a mesh or VPN network gives every node a stable private address wherever it roams. FrontierStack manages the common ones — by API on a router that supports it (OPNsense), or over SSH on a server:

9.14.3Tailnet: the whole-network view of Tailscale

The per-server Tailscale controls live inside each server's own pane and work over SSH: they answer “is the daemon up on this box”. The Tailnet pane answers the questions that span the whole network, which only Tailscale's own API can: paste an API access token (device read is enough — the pane never writes) and it lists every device with its addresses, OS, client version, owner, tags and last-seen time.

What earns the pane its place is the Needs attention list. It surfaces node keys that are about to expire — a scheduled outage, because when a key lapses the device silently drops off the tailnet until somebody re-authenticates it — devices waiting for approval, devices advertising routes nobody approved (the usual reason a subnet is unreachable even though the node is plainly up), and devices that stopped checking in weeks ago. Key expiry and pending approvals also raise Alerts.

9.14.4Running your own ZeroTier controller

ZeroTier's client is only the member side; networks are normally administered at my.zerotier.com. But every zerotier-one install can also be the controller for its own networks — fully self-hosted, no third party holding your membership list — and that path ships with no local administration UI at all. The ZeroTier Controller pane is that missing interface.

It shows the controller's identity and the networks it owns, and works the member-authorisation queue with one-click authorise/deauthorise. Members authorised but unseen for a fortnight are flagged, because an unused grant is a standing hole in the network. You can edit a network's name, privacy, routes and IP assignment pool, and write flow rules in ZeroTier's own rules language — compiled locally as you type, with templates for the common cases and a warning before you save a rule set that would lock everybody out.

Everything runs over SSH against the controller's own loopback API. The controller listens on 127.0.0.1:9993 and authenticates from a root-readable token, so FrontierStack never needs — and actively discourages — a publicly reachable controller API; the built-in audit flags it if one has been exposed anyway, along with loose file permissions and a missing backup. There is also a Prometheus export, a warm-standby backup/restore, and an assistant for migrating networks out of ZeroTier Central.

9.9UniFi: Cloud Gateways, Dream Machines and Superlink

Ubiquiti's consoles get their own pane, because a UniFi gateway is doing more than a generic router probe can see. It covers the console families alike — a Dream Machine (UDM, UDM Pro, UDM SE), a Cloud Gateway (UCG-Ultra, UCG-Max, UXG), a Superlink gateway, a Cloud Key or a self-hosted controller. The UniFi pane speaks both of Ubiquiti's APIs, and they answer different questions. A Site Manager key — one key, created at unifi.ui.com — lists every console on your account with its model, firmware and online state. That is the only way to learn a remote site has lost power or its internet connection, because a console that is off the network cannot tell you anything locally. A local console key, created on the console itself under Settings ▸ Admins & Users, unlocks what the gateway is doing right now.

Locally the pane shows WAN links with their ISP, latency and throughput, and marks which link is actually carrying traffic. That last detail matters: when a primary line drops, UniFi fails over silently to the backup, which is usually slower and often metered, and the normal way people discover this is the following month's bill. It also lists adopted devices and their firmware, firewall rules in the order the gateway evaluates them, the client list, and every port forward. Each enabled forward is a deliberate hole through the firewall, so the pane flags the ones that accept connections from any source address — correct for a public web server, worth a second look for anything else.

Alerts cover a console dropping offline, a WAN link going down, running on the backup link, a device leaving the network, and internet-exposed port forwards. The pane is deliberately read-only: rule and network changes stay in the UniFi console, where their validation lives. PoE switch ports are handled in the next section, and plain console reachability still appears in Router & Network alongside the other vendors.

The Site Manager key also lists UniFi Protect cameras and doorbells, read at most every five minutes. Tick Alert on a camera, or Alert on all Protect cameras, for offline alerts. A camera that is updating, or whose console is itself offline, is shown as unknown rather than down.

9.10Power over Ethernet: the power button for devices that have none

Access points, cameras, door controllers and desk phones have no power switch. Their only supply is the switch port they are plugged into, which means the recovery move for a wedged one — power-cycle it — normally involves a vendor web UI, or a walk to the cabinet.

The Power over Ethernet pane makes the port the button. Add a managed switch by IP and you get, per port: its PoE state (delivering power, searching, fault), powered-device class, priority and wattage where the switch reports it — plus power off/on and a proper power cycle. It also shows the switch's power budget: total watts, watts in use, and a warning when you cross the switch's own usage threshold, past which it starts shedding low priority ports — so port priority is editable here too.

This works broadly because PoE is standardised: RFC 3621's POWER-ETHERNET-MIB is implemented by essentially every managed PoE switch — Cisco, Aruba/HPE, Netgear, TP-Link/Omada, Ubiquiti, MikroTik, D-Link, Zyxel. Reading uses the SNMPv2c or SNMPv3 profile from Device Discovery. With SNMPv2c, switching a port needs a separate read-write community, added per switch and kept in your Keychain. With SNMPv3, it uses the authenticated profile only when that user has write permission on the switch. Cutting power deserves deliberate access and confirmation; FrontierStack does not expose arbitrary OID writes. With Monitor on, a port in fault state or a switch over its power budget raises an Alert — both otherwise stay invisible until someone notices a camera has gone dark.

9.11Internet Health and speed tests

The Internet Health pane is your view of the link itself. It continuously pings a list of Targets — Cloudflare's 1.1.1.1, Google and Quad9 DNS, two AWS regions and Tailscale's coordination server by default — showing latency and packet loss and re-testing every 30 seconds; hosts that block ICMP fall back to a TCP-connect latency on :443. The gear button in the Internet section's header opens the target-editing dialog — set the list up once and it stays out of the way. The same section carries an IPv6 verdict: each sweep checks whether a global IPv6 address is assigned, whether IPv6 traffic actually works (ping to Cloudflare/Google v6 anycast), and whether the network's advertised IPv6 DNS servers answer. The state it warns about loudest is advertised-but-broken IPv6 — the router hands out an address and an IPv6 DNS server, connections try IPv6 first, and everything stalls until IPv4 fallback; the pane says so in plain words, names the dead DNS server, and points at the router. The AI Administrator can run the same diagnosis with internet_speed (check=ipv6) and dig deeper with ping6/dig/scutil through its diagnose tool. The sidebar's Internet Health row carries a status dot fed by a light background sweep (at launch, then every 5 minutes): green when healthy, orange for broken IPv6 or heavy packet loss, red when every target is unreachable. Live Traffic graphs real-time throughput across every active interface; Addresses & Networks lists each interface, its subnet (a network you can reach directly) and the gateway. A built-in traceroute shows the ISP and transit providers your traffic crosses. Press Test Now in the Speed Test section — or ask the AI with internet_speed — to measure download, upload, latency and responsiveness, using the Ookla speedtest CLI if installed and Apple's networkQuality otherwise. While it runs, two speedtest.net-style dials show the download and upload live — needle, phase and the current Mbps — fed by Ookla's streaming output (the built-in networkQuality reports only at the end, so its dials wait), and the pane names the test server it connected to (provider and city), during the run and in the result. A test that fails now says why instead of ending silently. A Mac on Wi-Fi, though, measures its Wi-Fi as much as its ISP — so the same section can run the test from your router or a wired server instead: pick it under From Router / Server and FrontierStack runs the probe on that device over SSH (key authentication; routers as root), preferring an installed Ookla/speedtest-cli and falling back to a curl single-stream estimate. If the router measures much faster than the Mac, your bottleneck is the wireless hop, not the line — and the AI can do the same comparison via internet_speed with a source.

9.12Network Path: switches, hubs and hop-by-hop latency

The Network Path pane answers the physical question the IP tools cannot: which boxes does this connection actually cross, and which one slows it down? LAN Path reads your managed switches' bridge tables and LLDP neighbours over SNMP and draws the chain between this Mac and any LAN device — each link labelled with its port and speed, the slowest link flagged, and a dashed inferred box drawn where several devices share one switch port (the classic hidden unmanaged switch or hub, which cannot be queried directly). Locate a Device tracks one machine down: IP, MAC, maker (from the MAC prefix), type — and the exact switch port it is plugged into. Visual Traceroute charts each hop's round-trip time and highlights the hop that adds the most latency, so “is it my Wi-Fi, the ISP's first mile, or further out?” becomes a picture. Reading the switches uses the SNMPv2c or SNMPv3 profile set in Device Discovery; unmanaged gear stays invisible by nature, which is exactly what the inference is for. The pane fills itself in: on open it automatically maps the devices between this Mac and the router (and Map Mac → Router re-runs it). Device Link Speeds goes wider still — it surveys the negotiated Ethernet port speed of every known device from its switch port (both ends of a link negotiate the same rate), slowest and half-duplex links first: a NAS stuck at 100 Mbps on a gigabit network is usually a bad cable, an old unmanaged switch, or a mis-negotiating NIC, and this is where it shows up. Locate a Device also asks the device itself over SNMP what its ports negotiate, when it runs an agent.

9.13Debug Share: expose a localhost server, briefly

When you need to show a colleague or a phone a dev server running on localhost, the Debug Share pane exposes it for a session and then closes itself. Enter the port (or press Scan localhost to find a running server), choose how to Expose via, set an Auto-close time, and press Open debug session. Every share also closes automatically when FrontierStack quits.

The LAN forwarder has two extras. If the host firewall is on, the pane shows Open port in firewall to allow that port in the pf rules just for the session. And an Outside access picker can map a WAN port via UPnP, NAT-PMP or the OPNsense API and pair it with a DDNS host, so a LAN share becomes reachable from the public internet — the mapping is removed when the share closes. The AI Administrator can open, list and close sessions too (debug_share_open / _list / _close), including over MCP when "Allow changes" is on.

A Debug Share session is meant to be brief. To keep your own dev server reachable from your tailnet with no timer, turn on Also serve on Tailscale for it in the Localhost pane (Chapter 4): it answers on this Mac’s Tailscale address on the same port, stays off the LAN, and closes when the server stops. The AI Administrator can start a folder that way with debug_share action serve and report the address to open.

9.14Named tunnels: a permanent public hostname

A Quick Tunnel is deliberately throwaway. When you want a service on this Mac to be reachable permanently at a real address — a self-hosted app, an internal dashboard, a webhook receiver — use a named tunnel instead. It gives the service a stable hostname on one of your own Cloudflare zones (say app.example.com), survives reboots, and — like every tunnel — opens no inbound port: the Mac dials out to Cloudflare's edge, so there is nothing to forward and nothing for a port scan to find.

Create one in the Cloudflare pane's Named Tunnels section: New Tunnel…, then a hostname under one of your zones and the local port it fronts. FrontierStack drives the whole setup through the Cloudflare API using the token you already hold — it creates the tunnel, writes its ingress rule (hostname → http://localhost:PORT), adds a proxied CNAME pointing the hostname at <id>.cfargotunnel.com, and then installs the persistent daemon with cloudflared service install. That last step needs a one-time admin prompt (it writes a LaunchDaemon under /Library); cloudflared itself is fetched from Homebrew on first use. Untick Run on this Mac now if you only want the tunnel and DNS created, to run cloudflared on some other host. Delete unwinds all of it — daemon, DNS record and the account-side tunnel. The AI Administrator has the same three verbs (tunnel_create / tunnel_list / tunnel_delete), with creating one gated behind a red confirmation because it publishes a service to the internet.

A server is most exposed not when something attacks it, but when it quietly drifts: a firewall left open, a password login no one disabled, a certificate that expired last week, a mail server that will relay for anyone. FrontierStack treats hardening as a continuous, observable state rather than a one-time checklist. The Security pane is your console for the host in front of you; the AI Administrator (Chapter 13) carries the same checks across your whole fleet over SSH. Everything here is read-only until you ask for a change, and every change is one you could make by hand.

10.1The firewall: Application Firewall and pf

macOS ships two firewalls and FrontierStack reads both. The Application Firewall (ALF) is the per-app layer you set in System Settings; the Security pane reports its state — enabled, stealth mode, block-all-incoming, and how many app rules exist — so you can confirm at a glance that it is on. The pf packet filter is the lower, port-level layer, and this is the one FrontierStack manages directly.

App-managed pf rules live in their own file, ~/Library/Application Support/FrontierStack/pf-frontierstack.conf, loaded into a dedicated frontierstack anchor that is wired idempotently into the system /etc/pf.conf. Keeping rules in their own anchor means FrontierStack never edits Apple's base ruleset and your rules survive a reload without trampling anything. Adding or removing a rule reloads pf through an authenticated admin prompt.

From the AI side, the firewall_rule tool adds or removes a single allow/deny rule for a port, optionally scoped to a source address. It detects the target's operating system first: This Mac and remote macOS hosts get pf (the frontierstack anchor); Linux servers get ufw. It never sends a ufw command to a Mac or a pf rule to Linux.

10.2Intrusion prevention and the open-ports watch

An open port that has to stay open still needs a guard. The Security pane integrates two intrusion-prevention engines. fail2ban bans IP addresses that match abusive log patterns — SSH and Apache brute force are the classic cases; the pane shows whether it is installed and running, its jail count and how many addresses are currently banned, with a one-click Reload and a "write a starter jail.local" action that drops in a sane SSH jail without overwriting your overrides. CrowdSec adds a shared reputation network on top, showing its active decision count and a Metrics button. Both run as root services installed via Homebrew.

The Open Ports section lists every listener on the host. A companion watch — remote-control and screen-sharing exposure — specifically flags VNC/Screen Sharing (:5900), Apple Remote Desktop, AnyDesk, TeamViewer, Chrome Remote Desktop, Splashtop, RustDesk and Tailscale exit-node advertising, and turns red when someone is connected right now. The Recent Intrusions and Active Bans sections aggregate detections from fail2ban.log, CrowdSec, Suricata's eve.json and Wazuh's alerts.json, newest first; sources you do not run are simply skipped. A new ban, a new listener or an active inbound session can each raise an alert — configure delivery in Chapter 11. The same section checks FileVault on this Mac, judged by what the Mac holds: if it is off while the Mac has SSH access to linked servers or the app-managed SSH key, the row turns red and an alert is raised, because a lost or stolen laptop would give up the keys to your whole fleet. A Mac with no fleet credentials is left alone.

10.3SSH hardening

SSH is the single most valuable door on most servers, so the Security pane includes an SSH Hardening Audit. It reads the effective configuration with sshd -T — not just the file on disk, but what the daemon actually applies after its drop-ins — and flags the settings that matter: PermitRootLogin, PasswordAuthentication, and the rest. When SSH is reachable from the network the pane says so plainly, because that is exactly where the findings matter.

The baseline for an internet-facing host is key-based authentication with PasswordAuthentication no. Apply fixes by editing /etc/ssh/sshd_config.d/ rather than the main file, so package updates leave your hardening intact. FrontierStack's own fleet channel already follows these rules: it uses Ed25519 keys, BatchMode=yes, IdentitiesOnly=yes and host-key trust-on-first-use recorded in known_hosts (Chapter 8). If a host's key access breaks, the repair_ssh_access tool reinstalls the managed key using a one-time login password held in your local vault — the password is read on your Mac and never sent to the AI.

10.4Server Security: the posture check for a remote host

Everything above describes the Security pane for this Mac. The Server Security pane is its counterpart for a linked server: the same posture check, read over SSH, for any host in your fleet. Open a server's detail and click Check… beside Security, or open the pane directly and pick a server from the host menu. A single scan reports the SSH hardening that matters (PermitRootLogin, PasswordAuthentication, the listening port), whether a firewall is present and enabled (ufw, firewalld, nftables or raw iptables), the intrusion-prevention engines running (fail2ban, CrowdSec), the count of pending security updates (apt, dnf, yum), every service listening on all interfaces, and host-integrity smells — world-writable directories missing the sticky bit, unexpected SUID binaries.