Skip to content

Integration

How do I set up inping?

You create a free account and a project with a URL, and the inping runners check that URL with no installation. For server data you add the agent, which a single command installs. You add your own runners, notifications, a status page, the API and MCP as you need them.

The commands below are those of the guide, with placeholders such as <token>. In the app the dialog shows them filled in, and one click copies them. The complete installation guide explains each step.

Step 1

Create an account

Sign up with your email address and confirm it. The free plan needs no payment details and includes 1 project, 10 URLs and 25 pages per project, 2 agents and 1 own runner. The other plans are on the pricing page; payment runs through the reseller Paddle.

What applies next: you are admin of your team and invite members as admin, editor or viewer. Under Settings → Security you set up two-factor authentication or a passkey. For further customers you create separate teams through the team switcher.

Step 2

Create a project and URL

Under New project you create one project per application and enter its first URL. With Add URL you add more, with interval, expected status code and timeout, and if needed with Basic Auth or custom headers. Under Pages you choose what change detection should watch, and have the sitemap evaluated.

What happens then: the runners take the URL into their plan and report at the chosen interval. Response times and state appear in the dashboard. There is nothing to install, and up to this point you need no access to the server.

More on this under how inping measures availability.

Step 3

Install the agent on the server

Under Agents → Add agent you get a token that is shown exactly once and is valid for 24 hours. Inside a project you find the same dialog under Servers → Add agent, and the command then already names the project.

--project <project-id>=<path> gives the ID of the project from the project settings and the directory of its code. Repeat it for each project on the server.

Debian and Ubuntu

Also for Raspberry Pi OS, Linux Mint and other Debian-based systems with systemd. The service runs as its own user inping-agent, which must be able to read the project files.

Install

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh -s -- --project <project-id>=/srv/shop

Give read access to the project

sudo usermod -aG www-data inping-agent
sudo systemctl restart inping-agent

Check

systemctl status inping-agent          # active (running)
journalctl -u inping-agent -n 20
sudo inping-agent check                # the configuration from the platform

In detail in the article Monitor a Linux server.

Rocky Linux, AlmaLinux, CentOS Stream, Fedora

The same command as on Debian. SELinux can stay active, no policy module of its own is needed. Fedora packages are listed but not checked against advisories.

Install

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh -s -- --project <project-id>=/var/www/shop

Give read access to the project

sudo usermod -aG nginx inping-agent && sudo systemctl restart inping-agent

In detail in the article Monitor a Linux server.

Alpine Linux

Alpine has no systemd. You create the user beforehand and set up the OpenRC service afterwards; the complete recipe is in chapter 4 of the installation guide. It requires apk add curl.

Create the user and install

adduser -S -D -H -h /var/lib/inping-agent -s /sbin/nologin inping-agent
curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sh -s -- --project <project-id>=/srv/shop
macOS

For Intel and Apple Silicon. The command runs in Terminal and asks for the administrator password; the script creates the hidden user _inping-agent and two launchd services.

Install

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh -s -- --project <project-id>=/srv/shop
FreeBSD

FreeBSD 13 and 14, also in jails. fetch is part of the base system. The script sets up an rc.d service and the update task by cron.

Install as root

fetch -qo - https://www.inping.io/install.sh | INPING_TOKEN=<token> sh -s -- --project <project-id>=/usr/local/www/shop

Give read access to the project

pw groupmod www -m inping-agent
service inping_agent restart
Windows

Windows Server 2019 and newer, Windows 10 and 11, in PowerShell 5.1 or 7 as administrator. The service runs as the virtual account NT SERVICE\inping-agent.

Install (PowerShell)

$env:INPING_TOKEN = '<token>'; & ([scriptblock]::Create((irm https://www.inping.io/install.ps1))) -Project '<project-id>=D:\sites\shop'

Give read access to the project

icacls 'D:\sites\shop' /grant 'NT SERVICE\inping-agent:(OI)(CI)RX' /T
Restart-Service inping-agent

In detail in the article Monitor a Windows server.

Docker Compose

The agent runs next to your services and reports each one separately. The version and digest of the image are in the release notes under /agents/install, and in the dialog the values are already filled in. Registration reads the token from standard input, so it ends up in no file.

.env next to the Compose file

INPING_AGENT_IMAGE=ghcr.io/medienakzent/inping-agent:<version>@sha256:<digest>
INPING_API_URL=https://www.inping.io
INPING_PROJECT_ID=<project-id>

Addition to docker-compose.yml

services:
  inping-agent:
    image: ${INPING_AGENT_IMAGE:?set INPING_AGENT_IMAGE to a release}
    restart: unless-stopped
    read_only: true
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    configs:
      - source: inping-agent
        target: /etc/inping/agent.toml
    volumes:
      - inping-agent-state:/var/lib/inping-agent
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/host/root:ro
      - ./:/srv/app:ro
    networks: [default, inping]
    depends_on: [inping-docker-proxy]

  inping-docker-proxy:
    image: tecnativa/docker-socket-proxy:0.3.0
    restart: unless-stopped
    environment:
      CONTAINERS: 1
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks: [inping]

configs:
  inping-agent:
    content: |
      api_url = "${INPING_API_URL:?set INPING_API_URL}"
      state_dir = "/var/lib/inping-agent"

      [docker]
      endpoint = "tcp://inping-docker-proxy:2375"

      [[project]]
      id = "${INPING_PROJECT_ID:?set INPING_PROJECT_ID}"
      path = "/srv/app"

volumes:
  inping-agent-state:

networks:
  inping:
    internal: true

Register once and start

echo "<token>" | docker compose run --rm -T inping-agent register --token -
docker compose up -d

In detail in the article Monitor Docker containers.

Linux and macOS without root

For shared hosting, servers with no root access or development machines. Everything stays in the home directory, and the agent reads what your account may read. On Linux the user manager ends the agent at the last logout if lingering is not active.

Install

curl -fsSL https://www.inping.io/install.sh | INPING_TOKEN=<token> sh -s -- --user --project <project-id>=$HOME/www/shop

What happens then: within one interval, 60 seconds by default, the agent shows as Online, and the displays for CPU, memory and disks fill up. The host packages follow a few seconds after the start, the project packages with the first check. Vulnerabilities appear within one day. For a Synology, follow the procedure through Container Manager. The server clock should run on NTP, because reports more than 60 seconds ahead of the platform are rejected.

Step 4, optional

Run your own runner

inping operates its own runners. You need an additional one if you want to measure from your network or from a specific location. The runner runs on Linux with systemd (amd64, arm64) or as a Docker image.

Linux with systemd

curl -fsSL https://www.inping.io/install-runner.sh | INPING_TOKEN=<token> sudo --preserve-env=INPING_TOKEN sh

Docker: .env next to the Compose file

INPING_RUNNER_IMAGE=ghcr.io/medienakzent/inping-runner:<version>@sha256:<digest>
INPING_API_URL=https://www.inping.io

Docker: register once and start

echo "<token>" | docker compose run --rm -T runner register --token -
docker compose up -d

Allow private networks: /etc/inping/runner.toml

private_networks = true

The token is under Runners → Add runner for the team, or in the project under Runners → Add runner for that project only; both are reserved for team admins.

You allow private networks locally with private_networks = true in runner.toml; the platform releases them only to your own runners, never to its own. Loopback, link-local and cloud metadata addresses stay blocked even then.

What happens then: the runner exchanges the token for a key of its own and shows as Online within one minute. Its results count in the majority decision.

Step 5

Set up notifications

In the project, under Notifications → Add rule, you decide on which events who is informed: by email to the team, to up to ten external addresses and to the customer contacts of the project, or by webhook.

What happens then: external addresses and contacts get a confirmation email and only then notifications (double opt-in, valid for 72 hours). Webhooks send a signed POST with JSON. Check the header X-Inping-Signature, which is sha256=HMAC-SHA256(secret, timestamp + "." + body), and discard old timestamps. A delivery with a test event can be triggered directly.

The available events are listed under alerts and notifications.

Step 6, optional

Publish a status page

In the project settings, under Status page, you choose an address, that is inping.io/status/<name>. You mark which URLs are public in the dialog of each URL. You also set the logo, colour and texts there. For your own domain you set a CNAME such as status.client.example and have inping check it; the certificate is created automatically on the first request.

What happens then: the page can be reached with no login and shows the public URLs with names, state, 90 days of uptime and open incidents. Search engines stay out as long as you do not allow indexing. Details under status pages.

Step 7, optional

Connect the API and MCP

Under Settings → Security → API tokens you create a personal token with New token. By default it reads (projects:read) and, if you wish, may also change (projects:write). The token is shown only once; with no date it runs for one year. Every endpoint is in the API documentation.

What happens then: a connected AI assistant uses the MCP tools list-projects, get-project-status, create-project, list-issues and search-logs with the same permissions as you. For logs and errors from your application, enter the DSN from Project → Settings → Logs and errors in the Sentry SDK, see logs and errors.

First request: your teams

curl -H "Authorization: Bearer <token>" https://www.inping.io/api/v1/tenants

MCP in Claude Code

claude mcp add --transport http inping https://www.inping.io/mcp --header "Authorization: Bearer <token>"

No account

How do I check a project with no account?

A single command checks the packages of a project directory against OSV.dev, with no account and no installation. It runs on Linux, macOS and FreeBSD without root.

Check the current directory

curl -fsSL https://www.inping.io/scan.sh | sh -s -- .

Output as JSON

curl -fsSL https://www.inping.io/scan.sh | sh -s -- . --json > findings.json

In a CI job: fail only on high and critical

curl -fsSL https://www.inping.io/scan.sh | sh -s -- . --fail-on high || exit 1

What happens then: the script downloads the agent file for your system to a temporary directory, verifies it, runs the scan and removes it again. Every directory with a lock file counts as a project; node_modules, vendor and similar folders stay out. Only package names and versions go to OSV. inping additionally receives the report with project names and paths, packages, findings, operating system and agent version. With --no-report it stays local, and no account is created.

The output gives a link to a report with no login. It is unlisted and expires after 30 days if no project has been created from it; you can create a project from it, and the packages are then taken over directly.

The exit codes: 0 clean, 1 findings, 2 error or OSV unreachable. On Windows you install the agent and run inping-agent.exe scan <directory>.

Security

How safe is the agent on my server?

The agent only reads, writes solely to its own state directory, opens no port and talks to inping only outbound over HTTPS. The program files are signed, Docker images pinned by digest.

  • Its own user: the service runs as an unprivileged user, and you give it read access to the project specifically. On Linux it is limited by systemd hardening and, from kernel 5.13, its own Landlock sandbox.
  • Which files: you decide locally which project directories it reads for packages. You set log sources in inping, including file paths; it reads what its service user may read.
  • Signed versions: the script checks the SHA-256 sum of the download and the minisign signature if minisign is installed. On Windows only the SHA-256 sum is checked.
  • Updates: the agent does not replace itself. A separate update task runs every 6 hours with root rights, installs only signed versions and returns to the old one if the service does not start. With --user the agent needs no root at all.
  • Docker: the container runs with read_only, with no capabilities, and sees the Docker socket only through a proxy that rejects all writes. The proxy allows reads under /containers: it protects the host from the agent, not the contents of other containers.
  • Read the script first: https://www.inping.io/install.sh is public, and you can look at it before running it.

What network access does inping need?

WhoTargetHow
Agent and install scriptwww.inping.ioHTTPS, port 443
Runnerwww.inping.io and the websites it checksHTTPS, port 443, for the websites their address
Docker imagesghcr.ioHTTPS, port 443
One-line scanwww.inping.io and api.osv.devHTTPS, port 443
InboundnothingNo port has to be opened
The agent on the server reads local sources and sends only outbound over HTTPS to inpingYour server/proc, file systemsLock filesPackage databaseCron, timersDocker (via proxy)Agentread-only,own service userStatetoken, buffer443inpingHTTPS only,outbound only
The agent reads what is already on the server and writes only to its own state directory. It opens the connection itself: no open port, no access from outside.

Frequently asked questions

Questions about setting up inping

Do I have to open a port for inping?

No. The agent, runner and install scripts open only outbound connections: to inping by HTTPS on port 443, and the runner also to the addresses it checks, on their port. Nothing listens on the server.

Where do I get the registration token?

In the app when you add an agent or runner, under Agents → Add agent or Runners → Add runner. The token is shown exactly once and is valid for 24 hours. The dialog shows the finished command with the token for each system.

How does the agent update itself?

On systems with systemd, a timer checks every 6 hours for a new signed version, installs it, restarts the service and returns to the old version if it does not come up. macOS, FreeBSD and Windows have their own update tasks. On Alpine you run the install command again, in Docker you enter the version and digest in the .env file.

How do I remove the agent again?

The install script removes it with --uninstall, with --purge also the configuration, state and user. You then delete the agent in inping under Agents, choose the agent, Settings.

Can I try inping with no account?

Yes. The one-line scan checks the packages of a project directory against OSV.dev with no account and no installation. It runs on Linux, macOS and FreeBSD and exits with an error code on findings.