Local Deployment

This guide explains how to install the OpenOps docker-compose release on a local machine. Note that these settings are for testing purposes only and not for a production environment. Before following the instructions, make sure that your machine meets the system requirements for OpenOps.

Installing OpenOps

Run the following command in your terminal to install, update, configure and run OpenOps:

curl -fsS https://openops.sh/install | sh

This script supports macOS, Ubuntu and Windows (via WSL2 Ubuntu). If you can’t use the autoinstall script, follow the manual installation steps for your operating system below.

Show Installing manually on macOS

On macOS

Install Docker Desktop by following these instructions.

Open a new terminal window and run the following command to create a folder and download the OpenOps release files:

mkdir -p openops && cd openops && \
curl -OL https://github.com/openops-cloud/openops/releases/download/0.7.1/openops-dc-0.7.1.zip && \
unzip openops-dc-0.7.1.zip && cp -n .env.defaults .env

Open the .env file in the OpenOps installation folder. Change the values of the following variables that represent credentials. Do it now, as you won’t be able to change these values after the initial deployment:
- OPS_OPENOPS_ADMIN_EMAIL: the email of your OpenOps installation’s root admin account.
- OPS_OPENOPS_ADMIN_PASSWORD: the password of your OpenOps installation’s root admin account.
- OPS_POSTGRES_USERNAME: the username of the Postgres database that OpenOps uses.
- OPS_POSTGRES_PASSWORD: the password of the Postgres database that OpenOps uses.
- OPS_ANALYTICS_ADMIN_PASSWORD: the password of the OpenOps Analytics admin account (the username is hardcoded to admin).
Pull the images and run docker compose:
COMPOSE_PARALLEL_LIMIT=4 docker compose pull docker compose up -d
If you face a rate limit while downloading, run the command again.

You can now access the application by navigating to http://localhost.

Show Installing manually on Ubuntu Server

On Ubuntu Server

This procedure has been tested on Ubuntu Server 24.04.

During the Ubuntu Server installation, select Docker to be added to the installation. If you need to install Docker later, follow the instructions here.

# create and change directory
mkdir -p openops && cd openops
# download the release file
curl -OL https://github.com/openops-cloud/openops/releases/download/0.7.1/openops-dc-0.7.1.zip
# refresh package lists
sudo apt update
# install unzip
sudo apt install unzip
# decompress release file
unzip openops-dc-0.7.1.zip
# copy the defaults to env without overwriting existing files
cp --update=none .env.defaults .env

Identify your own IP address:

# find IP address
ip -o -4 addr show | awk '{print $2, $4}'

The output should look something like this:

lo 127.0.0.1/8 # loopback network interface - not here
enp1s0 192.168.1.50/24 # this looks more like it. We want this inet IP address without the subnet mask: 192.168.1.50
docker0 172.17.0.1/16 # docker network interface - not here

In this case, the IP address is 192.168.1.50.

Open the .env file in the OpenOps installation folder. Change the values of the following variables that represent credentials. Do it now, as you won’t be able to change these values after the initial deployment:
- OPS_OPENOPS_ADMIN_EMAIL: the email of your OpenOps installation’s root admin account.
- OPS_OPENOPS_ADMIN_PASSWORD: the password of your OpenOps installation’s root admin account.
- OPS_POSTGRES_USERNAME: the username of the Postgres database that OpenOps uses.
- OPS_POSTGRES_PASSWORD: the password of the Postgres database that OpenOps uses.
- OPS_ANALYTICS_ADMIN_PASSWORD: the password of the OpenOps Analytics admin account (the username is hardcoded to admin).
In the .env file, find the OPS_PUBLIC_URL variable and replace its value, http://localhost, with the IP address that you’ve previously identified. In our example, the IP address would be http://192.168.1.50.

Pull the images and run docker compose:

# download the docker volumes and images
COMPOSE_PARALLEL_LIMIT=4 sudo docker compose pull
# launch the application
sudo docker compose up -d

If you face a rate limit while downloading, run the command again.

Show Installing manually on Windows

On Windows (with PowerShell)

Install Docker Desktop by following these instructions.

Add a new folder for OpenOps in your PowerShell console:

New-Item -ItemType Directory -Force -Path openops
Set-Location openops

Download the OpenOps release files:

Invoke-WebRequest -Uri "https://github.com/openops-cloud/openops/releases/download/0.7.1/openops-dc-0.7.1.zip"
Expand-Archive -Path "openops-dc-0.7.1.zip" -DestinationPath .
if (-Not (Test-Path ".env")) {
    Copy-Item ".env.defaults" ".env"
}

Open the .env file in the OpenOps installation folder. Change the values of the following variables that represent credentials. Do it now, as you won’t be able to change these values after the initial deployment:
- OPS_OPENOPS_ADMIN_EMAIL: the email of your OpenOps installation’s root admin account.
- OPS_OPENOPS_ADMIN_PASSWORD: the password of your OpenOps installation’s root admin account.
- OPS_POSTGRES_USERNAME: the username of the Postgres database that OpenOps uses.
- OPS_POSTGRES_PASSWORD: the password of the Postgres database that OpenOps uses.
- OPS_ANALYTICS_ADMIN_PASSWORD: the password of the OpenOps Analytics admin account (the username is hardcoded to admin).
Run docker compose:
$env:COMPOSE_PARALLEL_LIMIT = "4" docker compose pull docker compose up -d
If you face a rate limit while downloading, run the command again.

Updating OpenOps to a newer version

See Updating OpenOps.

Cloud templates

On localhost, cloud templates may not be able to load when using the Safari browser.

Configuring Slack approvals

If you would like to run a workflow that uses Slack approvals in a local installation, you should set the following variable in your .env file:

OPS_SLACK_ENABLE_INTERACTIONS=false

This will open a new tab in your default browser when you approve or reject an action. You can safely close the tab after the action is completed.

After updating your .env file, restart the containers:

sudo docker compose down && docker compose up -d

Disabling host validation

By default, OpenOps does not allow workflows to call internal network addresses such as 127.0.0.1 or 192.168.0.0. This affects HTTP and SMTP actions, as well as webhook triggers. Host validation protects users from creating workflows that could accidentally or maliciously access internal services, scan networks, or escalate privileges. You may need to disable this check in certain circumstances, such as in non-production deployments or when workflows intentionally interact with internal-only infrastructure. To disable host validation, open the .env file in your installation folder and set the OPS_ENABLE_HOST_VALIDATION environment variable to false. After making any changes to the .env file, restart the OpenOps containers:

sudo docker compose down
sudo docker compose up -d

Disabling this check removes an important safety guard and may allow workflows to access internal infrastructure. Use caution and avoid disabling it in production.

Configuring allowed SMTP ports

By default, OpenOps allows SMTP connections on ports 25, 465, 587, and 2525. Administrators can customize which SMTP ports are available by setting the OPS_SMTP_ALLOWED_PORTS environment variable in the .env file. To configure allowed SMTP ports, open the .env file in your installation folder and set the OPS_SMTP_ALLOWED_PORTS variable to a comma-separated list of port numbers:

OPS_SMTP_ALLOWED_PORTS=25,465,587,2525

Port numbers must be valid TCP ports in the range 1-65535. At least one valid port must be configured. Invalid port numbers will be filtered out.

After making any changes to the .env file, restart the OpenOps containers:

sudo docker compose down
sudo docker compose up -d

Using Azure CLI in workflows: running with local credentials

It is possible to share your local session with the platform for local applications. To do this, you need to set two environment variables in the .env file under the installation folder:

OPS_ENABLE_HOST_SESSION=true: enables sharing of the host session with the platform container.
HOST_AZURE_CONFIG_DIR="~/.azure": defines the path to the host machine’s Azure configuration folder that will be shared with the platform container.

Using Google Cloud CLI in workflows: running with local credentials

It is possible to share your local Google Cloud CLI session with the platform for local applications. To do this, you need to set two environment variables in the .env file under the installation folder:

OPS_ENABLE_HOST_SESSION=true: enables sharing of the host session with the platform container.
HOST_CLOUDSDK_CONFIG="~/.config/gcloud": defines the path to the host machine’s Google Cloud configuration folder that will be shared with the platform container.

Support

Feel free to join our Slack community if you have any questions or need help with your installation.

Introduction to OpenOps

Getting Started with OpenOps

Workflow Management

Cloud Access

AI Assistance

Reporting and Analytics

Paid Features

Integrations

Cookbook

Contributing to OpenOps

Installing OpenOps

On macOS

On Ubuntu Server

On Windows (with PowerShell)

Updating OpenOps to a newer version

Cloud templates

Configuring Slack approvals

Disabling host validation

Configuring allowed SMTP ports

Using Azure CLI in workflows: running with local credentials

Using Google Cloud CLI in workflows: running with local credentials

Support

​Installing OpenOps

​On macOS

​On Ubuntu Server

​On Windows (with PowerShell)

​Updating OpenOps to a newer version

​Cloud templates

​Configuring Slack approvals

​Disabling host validation

​Configuring allowed SMTP ports

​Using Azure CLI in workflows: running with local credentials

​Using Google Cloud CLI in workflows: running with local credentials

​Support

Installing OpenOps

On macOS

On Ubuntu Server

On Windows (with PowerShell)

Updating OpenOps to a newer version

Cloud templates

Configuring Slack approvals

Disabling host validation

Configuring allowed SMTP ports

Using Azure CLI in workflows: running with local credentials

Using Google Cloud CLI in workflows: running with local credentials

Support