Self-Host ODS on Apple Silicon: Setup and Remote Access

What ODS provides on an Apple Silicon Mac

ODS, or Osmantic Deployment System, is a self-hosted AI server stack. Its V3 documentation describes a system designed to turn a PC, Mac, or Linux computer into a private AI server. For a Mac user, the practical result is a collection of locally hosted services that can be opened from a browser instead of relying entirely on a hosted AI interface.

The current ODS V3 release is explicitly a pre-release. It is in public testing and refinement ahead of the official V3 launch. That distinction matters because a successful installation does not imply production readiness, completed compatibility testing, or stable behavior across every supported workflow. The release notes state that fleet qualification remains in progress and that some complex generated applications and event research workflows still have known acceptance failures.

The official installation path for Linux and macOS uses a hosted shell bootstrap. Docker must already be installed and running. After installation, the two browser endpoints documented for this workflow are:

• Open WebUI: http://localhost:3000
• Portal: http://localhost:3001/pixel

Open WebUI is the most direct target when the goal is remote browser access to AI chat. Portal is a separate ODS interface and should be treated as a separate service, even though both are part of the same local deployment. You do not need to expose both. In most cases, publishing only the specific interface you need is safer and easier to troubleshoot.

Prerequisites for installing ODS on Apple Silicon

Complete the preparation work before running the ODS bootstrap. The installer expects Docker to be available, and a partially configured container environment can make later failures difficult to distinguish from ODS problems.

An Apple Silicon Mac

This guide is specifically for a Mac using Apple Silicon. Confirm that you are working on the intended Mac and that you have permission to install and run Docker-based services on it. If the Mac is managed by an employer or school, review the applicable device and network policies first.

ODS can require substantial local resources depending on the AI workloads, models, and services you choose. The available evidence does not establish one universal minimum for memory, storage, or processor configuration, so we do not recommend inventing a fixed hardware threshold. Check your available disk space and memory before installation, then monitor actual use during testing.

Docker installed and running

Docker is a documented prerequisite for the macOS installation. Install a Docker distribution that supports your Apple Silicon Mac, start it, and wait until its container engine is ready. Merely having a Docker application in the Applications folder is not enough if the engine is stopped.

Before proceeding, confirm that Docker can start containers successfully. If Docker reports a startup, virtualization, permission, storage, or networking error, resolve that problem before running the ODS installer. ODS cannot provide its services when the underlying container runtime is unavailable.

Administrative awareness and installer review

The macOS workflow uses a hosted shell bootstrap. A hosted bootstrap is convenient, but it also means you are obtaining executable instructions from a remote location. ODS is under active development, and its default main-based installer can change after a tagged release.

Review the current command and script shown in the official ODS repository immediately before use. Confirm that the repository owner, branch, and script path are the ones you expect. If your environment requires pinned, signed, or independently audited installation artifacts, the continuously changing bootstrap channel may not satisfy that requirement.

Local browser access

You need a browser on the Mac for the first verification. Test the services through localhost before introducing remote access. This separates application problems from tunnel configuration problems and gives you a known working baseline.

A Localtonet account and client for the remote-access stage

Localtonet is not required to install ODS or use it locally. It becomes relevant only after ODS is working on the Mac. For remote access, install and run our client on the same Mac, or on another device that can reach the Mac’s local service. You will also need a device-specific authentication token and an available relay server selection from the current dashboard.

Do not place the device token in screenshots, shell history shared with others, public notes, or configuration examples. Tokens identify the client device that runs the tunnel and must be kept private.

Install ODS using the official macOS bootstrap

The supported evidence for this workflow establishes a short installation sequence: Docker must be installed and running, and Linux or macOS users then run the hosted shell bootstrap provided by the ODS project. Because the bootstrap channel follows an actively changing pre-release branch, the safe approach is to retrieve its current command from the official repository instead of relying on a copied historical command.

Do not configure Localtonet during the bootstrap. First establish that ODS completed and that its documented browser endpoints respond locally. A tunnel cannot repair a failed container, missing service, unavailable model runtime, or incomplete ODS installation.

Verify Open WebUI and Portal locally

Verification should proceed one interface at a time. Begin on the Mac where ODS is installed and keep Localtonet stopped until both the relevant local endpoint and its expected page are confirmed.

Test Open WebUI

Open a browser on the Mac and visit:

http://localhost:3000

A successful result should display the Open WebUI interface rather than a browser connection error. Complete any setup presented by the application and determine how user access is controlled before considering remote exposure.

Do not treat the appearance of a page as a complete AI functionality test. If your intended workflow includes selecting a model and submitting a chat request, perform that test locally. Confirm that the interface can reach the required local backend and that a response completes. The release notes indicate that broader model-switching qualification was not complete, so test the exact model and workflow you intend to use.

Test the ODS Portal

In a separate browser tab, visit:

http://localhost:3001/pixel

Confirm that the Portal route loads. Because this interface uses port 3001 and a specific /pixel path, a successful Open WebUI test on port 3000 does not prove that Portal is available.

The V3 release notes say that Hermes opens without an owner card on default installations. Administrators can opt into the owner-card gate, while internal API and WebSocket authentication remain in place. Do not interpret internal API authentication as proof that every browser-facing route is appropriate for unrestricted public access. Review the actual access behavior of your installation.

Distinguish common browser results

Operate and update a pre-release ODS installation

ODS V3 requires more cautious operational practices than a stable, fixed production package. Record when you installed it, which branch or release channel you used, and which workflows you verified. This information is valuable if behavior changes after an update.

Keep the installation channel clear

The V3 release tag is fixed to a particular commit, while the default README installers use main. Main can include later qualification and security fixes that are not part of the fixed tag. Before updating, determine whether your installation follows a tagged source snapshot or the main-based installer channel.

Avoid assuming that a numeric version label tells the entire story. Two installations displaying similar V3 metadata can differ if one came from the fixed tag and another received later main-branch changes.

Handle the V3 security notice correctly

The V3 release notice reports that the fixed v3.0.0 release is affected by a critical security advisory identified as GHSA-vqpg-pvjj-4cmq. It states that the fix is on main and that the README installers use main.

The same notice warns that running ods update alone does not apply code fixes. Existing installations must follow the project’s current “Updating an existing installation” procedure. Because the exact update procedure is not included in the supplied evidence and can change, retrieve it from the current official ODS README rather than substituting an invented command sequence.

Use a controlled change process

Before an update, note which local endpoints work and which model or application workflow you rely on. Stop remote exposure while making significant changes. After updating, verify Docker, Open WebUI, Portal, authentication behavior, and the intended AI request locally.

If the updated local service behaves differently, keep the Localtonet tunnel stopped until you understand the change. This prevents an incomplete setup page, unexpected route, or changed access policy from becoming publicly reachable.

Back up data according to what your installation actually stores

The supplied ODS evidence does not establish one universal backup command, volume name, or data directory for this pre-release workflow. Do not guess these paths. Inspect the current ODS configuration and documentation for the version you installed, identify the Docker volumes or host directories that contain persistent data, and test restoration before relying on the backup.

Access ODS remotely with a Localtonet HTTP tunnel

Once Open WebUI or Portal works locally, Localtonet can expose the selected HTTP service. Our client on the Mac establishes an outbound connection to a Localtonet relay server. The resulting tunnel provides a public address without requiring inbound router port forwarding, firewall changes, VPN setup, or a public IP address.

Create a separate HTTP tunnel for the interface you intend to publish. For Open WebUI, target local port 3000. For Portal, target local port 3001; users can then open the assigned public address with the /pixel route when required.

HTTP tunnels can use a random subdomain, a custom subdomain where supported, or a custom domain. These process types serve the same local content through a public HTTPS address. Custom-domain DNS requirements can change, so consult the current dashboard and Localtonet HTTP tunnel documentation before making DNS changes.

Secure a remotely accessible AI interface

A service bound only to localhost has a much smaller exposure surface than the same service published through a public URL. Tunneling changes reachability, not the application’s authorization model. Before starting the tunnel, determine what an unauthenticated visitor can see or do.

Finish first-run setup locally

Complete account creation, owner setup, or other initialization before public exposure. Test with a private browser session to see whether an unauthenticated user reaches a sign-in screen, a setup screen, or the application itself.

Expose only the interface you need

If your goal is remote AI chat, begin with Open WebUI on port 3000. Do not expose Portal merely because it is available. Each additional public interface adds another route that must be understood, monitored, and secured.

Use least privilege inside ODS

Avoid sharing administrative credentials for routine chat access. Use the narrowest application permissions supported by the installed version. The supplied evidence does not establish every current ODS or Open WebUI authorization setting, so verify the actual controls in your installation rather than assuming a particular default.

Protect secrets and conversations

AI systems can contain model credentials, provider tokens, prompts, generated files, and conversation history. Never put authentication tokens into a public URL or article. Review what the interface displays, what it stores, and whether remote users can access configuration or other users’ data.

Stop remote access during maintenance

Stop the tunnel before upgrades, recovery, or access-control changes. Recheck the service locally after maintenance, then restart the tunnel and perform an external authentication test. Delete tunnels that are no longer required instead of leaving unused public endpoints configured indefinitely.

Troubleshoot ODS installation and remote access

Docker is installed but ODS does not start

Confirm that Docker’s engine is running, not merely that the application is installed. Review the terminal output from the bootstrap and the state of the relevant containers. If Docker itself reports a resource, permission, virtualization, network, or storage problem, resolve that first.

Also confirm that you used the current official installer instructions. A command copied from an old article or fork can point to a different script or branch than the current ODS workflow.

Open WebUI does not load on port 3000

Test http://localhost:3000 directly on the Mac. If the browser cannot connect, the problem is local and should be resolved before examining Localtonet. Review whether installation completed and whether the service responsible for Open WebUI is running.

If a different application already occupies port 3000, do not invent a replacement ODS port. Check the current ODS documentation and configuration for a supported way to resolve the conflict.

Portal does not load

Use the complete documented address, http://localhost:3001/pixel. Testing only the root of port 3001 is not the same as testing the documented Portal route. If the exact route fails while Open WebUI works, investigate Portal as a separate service.

The page loads but model requests fail

Keep the test local. A tunnel transports HTTP traffic but does not install models, repair model runtimes, supply missing credentials, or resolve application configuration. Reproduce the failure at the localhost address and inspect the ODS service responsible for the request.

Because V3 qualification is still in progress, record the model, operation, and visible error. A basic page-load test is not sufficient evidence that every model-switching or generated-application workflow is working.

The Localtonet public address is offline

Confirm all lifecycle conditions:

• The Localtonet client is running and connected.
• The selected device token belongs to that client.
• The intended tunnel has been started, not merely created.
• The chosen relay selection is currently available.
• The local target points to the correct ODS port.
• The ODS page still works through localhost.

If the Localtonet client runs on the same Mac, use the loopback target for the selected port. If the client runs on another device, 127.0.0.1 refers to that other device, not the ODS Mac. In that arrangement, the target must be a local network address that the client device can reach, and ODS must listen in a way that permits that connection.

The public page loads but the Portal path returns the wrong page

Verify that the tunnel targets port 3001 and that the remote URL includes /pixel. Do not point a Portal URL at the Open WebUI tunnel on port 3000. Keep each service’s public address clearly labeled.

Behavior changed after an ODS update

Determine whether the update changed the installed code, configuration, containers, or only displayed version metadata. Remember that the project specifically warns that ods update alone does not apply the code fixes described by the V3 security notice.

Stop the public tunnel, follow the current official existing-installation update process, and repeat the complete local verification sequence. If access-control behavior changed, do not restore public access until it has been reviewed.

Frequently asked questions