Install OpenOps and Access It with Localtonet

What OpenOps provides

OpenOps is a no-code FinOps automation platform designed to turn cloud financial management findings into repeatable workflows. It is intended for processes such as allocation, unit economics, anomaly management, workload optimization, tagging, budgeting, reporting, governance, and controlled de-provisioning. Instead of limiting a team to a fixed set of reports, OpenOps provides a workflow editor that can be used to customize existing automation or build new processes.

The platform is also designed to support collaboration among FinOps practitioners, engineers, DevOps teams, finance teams, and leadership. This matters because a cloud cost recommendation often cannot be implemented safely by one person. A workflow may need data from a cloud provider, technical review from an application owner, financial approval, and a record of what happened. OpenOps includes human-in-the-loop controls for workflows where an automated action should pause for a decision.

The self-hosted edition is useful when an organization wants to operate OpenOps on infrastructure it controls. OpenOps is licensed under the Apache License 2.0. Self-hosting, however, also makes the operator responsible for host security, updates, persistent data, credentials, backups, application access, and the network path used to reach the interface.

Prerequisites and decisions before installation

The available OpenOps project material confirms that the self-hosted deployment is based on Docker Compose, but the supplied evidence does not state a supported operating-system list, minimum CPU or memory allocation, minimum disk capacity, required Docker version, required Compose version, or architecture matrix. It also does not establish the exact production sizing required for a given number of integrations or workflows.

Before installation, choose a host that can run the Docker Compose deployment and that has enough capacity for the workload you intend to create. Verify host compatibility against the current OpenOps documentation and the current deployment files rather than assuming that an arbitrary Docker environment is supported. Capacity needs can change as workflows, stored data, analytics, integrations, and concurrent users increase.

Container tooling

You need a working container environment that provides Docker Compose functionality. Confirm that the Docker engine is running and that the account performing the installation is authorized to create containers, networks, volumes, and published ports. The precise installation procedure for Docker depends on the operating system and is not specified by the supplied OpenOps material.

Project files and release selection

Obtain OpenOps from its official project repository or an official project release. The repository contains a compose.yaml file and an environment template named .env.template. Those filenames establish that the project supplies Compose and environment configuration material, but they do not by themselves establish which values must be changed for a particular release.

Choose a deliberate release or revision rather than assuming that an unpinned moving branch is appropriate for a production deployment. Read the release notes before upgrading, and retain a record of the exact revision and configuration used. This makes a failed upgrade easier to diagnose or reverse.

Network placement

Decide where both OpenOps and the Localtonet client will run. The Localtonet client must run on a device that can reach the OpenOps HTTP endpoint. They may run on the same host, but they do not have to. If they run on separate devices, the OpenOps endpoint must be reachable from the Localtonet client over the local network.

Remember that loopback addresses are local to a network namespace. If a Localtonet client runs directly on the host, a host-published OpenOps endpoint can be used as the target. If the client runs inside another container, that container's loopback address does not refer to the Docker host or to the OpenOps application container. Use a network arrangement in which the client can genuinely reach the selected address and port.

Application secrets and cloud permissions

OpenOps workflows may connect to cloud providers and other operational systems. Do not place real production credentials into configuration until you understand how the selected integration stores and uses them. Begin with the least privilege needed for the intended workflow. A reporting workflow may not require permission to change resources, while a remediation workflow may require narrowly scoped write permissions.

Install and configure OpenOps with Docker Compose

The official project identifies Docker Compose as the ready-to-install self-hosting method. The repository contains the Compose file and environment template needed to define the deployment. However, the evidence supplied for this draft does not include the official quick-start commands, required Docker versions, exact environment setup, service names, image tags, local port, startup command, or initialization sequence.

For that reason, this article does not present an unverified command block. A plausible-looking command copied from a different OpenOps revision could start the wrong image, omit a required configuration step, overwrite local changes, or publish an unintended port. The safe installation workflow is to keep the Compose file, environment template, and instructions from the same project revision together.

1. Select and record the OpenOps revision

Start with the official OpenOps repository or an official release. Record the tag or commit that you intend to deploy. Review its release information for migration notices, fixes, or configuration changes. Avoid combining a current Compose file with environment instructions from another release.

2. Obtain the complete deployment files

Download or clone the selected project revision so that the Compose file and related configuration are available together. The repository includes compose.yaml, .env.template, Docker build files, and other project material. Do not extract only one file unless the instructions for that exact revision explicitly say that it is sufficient.

3. Inspect the Compose definition before running it

Review the Compose file to identify the services it creates, the container images or build contexts it uses, its volume declarations, dependency relationships, and any ports it publishes to the host. The supplied project extract does not establish the service names or port mappings, so those values must be read from the selected revision.

This inspection also tells you whether the browser interface binds only to the local machine, to a LAN interface, or to all host interfaces. Binding behavior directly affects local security and determines which target address the Localtonet client can use later.

4. Build the environment configuration from the matching template

Use the included .env.template and the documentation for the chosen revision to create the runtime configuration expected by its Compose deployment. Determine which entries are mandatory, which are optional, and which require unique secrets. Do not assume that a template value is secure for production merely because it allows a development deployment to start.

Keep the resulting environment file out of public repositories, shared chat logs, screenshots, and support messages. If a secret is accidentally disclosed, rotate it rather than only deleting the visible copy.

5. Start the deployment using the documented command for that revision

Run the Docker Compose startup procedure specified by the current OpenOps quick-start documentation. The exact command is intentionally not reproduced here because it was not included in the supplied evidence. Observe the initial output rather than immediately moving on to the tunnel.

Image downloads, builds, database initialization, or other startup work may take time. A container being created does not prove that the application is ready. Review service states and logs using the Docker Compose operations documented for the installed version.

6. Complete any documented first-run setup

If the selected OpenOps release presents an initialization or account-creation workflow, complete it locally. The supplied evidence does not specify default usernames, passwords, or a fixed first-run sequence, so this guide does not invent them. Do not search for or rely on presumed default credentials.

7. Record the verified local endpoint

From the actual Compose port mapping and a successful browser test, record the precise HTTP endpoint that works from the Localtonet client device. You need a local IP address or hostname and a port. Do not assume a common development port, and do not use a container-internal port unless the Localtonet client shares a network where that address is reachable.

Verify OpenOps locally before creating a tunnel

Local verification creates a known-good baseline. If the interface works locally but not remotely, you can concentrate on target reachability and tunnel configuration. If the interface does not work locally, changing the tunnel will not repair the OpenOps deployment.

Check the Compose workload

Use the Docker and Compose inspection commands appropriate to the installed versions to confirm that the expected services are running. Look for containers that repeatedly restart, exit immediately, remain unhealthy, or report dependency failures. Review logs for configuration errors, missing values, failed migrations, permission problems, unavailable dependencies, and port conflicts.

Do not assume that every container must publish a host port. Multi-service applications commonly keep supporting components on an internal container network and publish only the browser-facing service. Use the Compose definition as the authority for the selected revision.

Open the interface from the host

Load the exact host address and port published by the Compose deployment. Confirm that the browser receives an OpenOps page rather than a Docker error, unrelated service, generic proxy response, or blank connection. If the deployment redirects between paths or schemes, note the final working URL.

Test from the Localtonet client device

If Localtonet will run on another device, test the same endpoint from that device before creating the tunnel. A browser, HTTP client, or equivalent local test can establish basic reachability. If the host itself can open OpenOps but the Localtonet device cannot, investigate the OpenOps bind address, LAN routing, host firewall, and container port publication.

Exercise an application-level function

A page loading is only the first check. Confirm that you can authenticate through the configured access flow and reach the expected OpenOps interface. Open a workflow-related page, OpenOps Tables, or OpenOps Analytics if enabled in your deployment. Verify that navigation and API-backed page content work, since a partially initialized application can render an initial page while later requests fail.

Create a baseline for troubleshooting

Record the working local URL without including credentials, tokens, or sensitive query strings. Note which device performed the test and whether the target uses an IP address or hostname. This verified endpoint is the only endpoint that should be entered as the Localtonet HTTP tunnel target.

Access the verified OpenOps interface with Localtonet

Once OpenOps works from the device that will run our client, an HTTP tunnel is the appropriate Localtonet tunnel family for its browser-based interface. The client establishes an outbound connection to a Localtonet relay server, so this workflow does not require inbound router port forwarding, a public IP address, VPN setup, or an inbound firewall change.

An HTTP tunnel points to a local IP address and port. Its public side uses an HTTPS address. HTTP tunnel process types can use a random subdomain, a custom subdomain where supported, or a custom domain. These process types change how the public address is selected, not which OpenOps content the tunnel serves.

For the current dashboard workflow and field names, consult our Localtonet HTTP tunnel documentation. Current product documentation should be treated as authoritative when an option differs by client version, account, plan, or dashboard release.

Secure a remotely reachable FinOps interface

A FinOps platform may display cost information, account metadata, workflow history, resource identifiers, approval decisions, and integration status. Depending on its configured permissions, it may also initiate actions against cloud infrastructure. Treat public reachability as a security boundary change even when the tunnel is intended only for a small internal team.

Require application-level authentication

The public URL should lead to an authenticated OpenOps experience, not an open dashboard or an unfinished initialization screen. The supplied OpenOps evidence does not establish the authentication methods available in every release, so configure the mechanism supported by the version you install and test it before distributing the URL.

Use least-privilege cloud credentials

Scope each integration to the minimum accounts, projects, subscriptions, resources, and actions needed by the workflow. Separate read-only discovery from remediation where practical. A workflow that calculates allocation or reports anomalies should not automatically receive broad destructive permissions.

Keep secrets outside public material

Do not expose the OpenOps environment file, cloud credentials, webhook secrets, Localtonet device token, session data, or private endpoint details. Redact them from screenshots and logs. If a secret appears in a public location, assume it has been copied and rotate it.

Control who receives the public URL

A hard-to-guess address is not a substitute for authentication. Share access only with intended users, review application accounts regularly, and remove access when a team member or contractor no longer needs it. If your security policy requires stronger restrictions, evaluate the controls available in the current OpenOps and Localtonet configurations before exposure.

Test actions with low-risk resources

Before enabling a workflow that modifies infrastructure, test its inputs, conditions, approval points, and outputs against a limited non-production scope. Review workflow logs and verify that failure handling does not turn a partial error into an unsafe retry or repeated action.

Routine operation, maintenance, and upgrades

A useful self-hosted deployment needs more than a successful first startup. Document the OpenOps revision, configuration process, persistent storage, backup schedule, local endpoint, Localtonet device, and tunnel ownership. Keep secrets out of that operational record, but record where authorized administrators can retrieve or rotate them.

Starting and stopping services

Use the Docker Compose lifecycle commands documented for the installed OpenOps revision and your Docker environment. A normal stop should preserve persistent data, but that depends on how the deployment defines volumes and how an operator removes containers. Do not use destructive cleanup options until you know exactly which named volumes or host paths contain OpenOps data.

The Localtonet tunnel has a separate lifecycle. OpenOps can be healthy while its tunnel is stopped, and a tunnel can be running while OpenOps is unavailable. When remote access fails, check both states independently.

Backups

Identify every persistent component from the selected Compose file and current OpenOps documentation. Back up application data and the configuration needed to reconstruct the deployment. A copy of compose.yaml alone is not a data backup.

Protect backup copies because they may contain sensitive operational or financial data. Test restoration in an isolated environment. A backup procedure is not complete until the team has demonstrated that it can restore a usable deployment.

Upgrades

Review the target release notes and current OpenOps upgrade instructions before changing images or project files. Back up persistent data, preserve the current configuration, and note the running revision. Do not assume that replacing containers is sufficient if a release introduces a migration or new required environment value.

After upgrading, repeat the local verification sequence before re-enabling or relying on remote access. Confirm service health, authentication, workflow pages, tables, analytics, integrations, and a low-risk workflow operation. Then test the Localtonet URL.

Monitoring availability

Remote availability depends on several components: the OpenOps services, Docker, the host, the local network path, the Localtonet client, and the tunnel state. Monitor each layer appropriately. The tunnel is available only while its selected client is connected and the tunnel is running.

Troubleshooting OpenOps and the Localtonet tunnel

The OpenOps page does not load locally

Start with Docker Compose rather than Localtonet. Confirm that the expected services exist and remain running. Review their logs for missing environment values, startup dependencies, permission failures, migrations, unavailable storage, or port conflicts. Compare the active project files with the instructions for the exact revision you selected.

Recheck the published port in compose.yaml. A container may listen internally without publishing that listener to the host. Because the supplied evidence does not establish a default OpenOps port, do not troubleshoot against an assumed port number.

The host can open OpenOps, but the Localtonet device cannot

This normally indicates a reachability difference between the two devices or network namespaces. Check the application's bind address, the host's LAN address, Docker's published-port configuration, local firewall rules, and network routing. If the Localtonet client runs in a container, remember that its loopback interface belongs to that container.

The tunnel exists, but no public address works

Verify that the intended Localtonet client is connected and that the tunnel was explicitly started. Tunnel creation and tunnel startup are separate actions. Also confirm that the selected device token belongs to the device that can reach OpenOps and that the selected relay server remains available in the current dashboard.

The public address returns an error or the wrong page

Compare the tunnel target with the locally verified IP address and port. Check whether another service occupies that port. Retest the target directly from the Localtonet client device. If the local test now fails, repair OpenOps or local networking before modifying the tunnel.

The login page appears, but later requests fail

Inspect OpenOps and browser errors for API, session, callback, or application configuration problems. The supplied evidence does not establish whether a particular OpenOps release requires a configured external URL, trusted origin, proxy header, or callback setting. Do not invent one. Check the documentation for the installed release and change only settings it explicitly supports.

The deployment worked until an update

Compare the previous and new release instructions, Compose definitions, image references, and environment templates. Look for newly required values or migrations. Restore from a tested backup if the documented recovery process calls for it. Avoid repeatedly recreating volumes, since destructive cleanup can turn an application problem into data loss.

The remote URL became unavailable unexpectedly

Check whether the OpenOps host restarted, Docker stopped, the Localtonet client disconnected, or the tunnel was stopped. Then check local OpenOps reachability from the client device. This sequence prevents time being spent on public routing when the underlying service is offline.

Frequently asked questions