Harp on Nextcloud AIO

â„č Support 📩 Appliances (Docker, Snappy, VM, NCP, AIO)
, , , ,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can. :heart:

The Basics

  • Nextcloud Server version (e.g., 29.x.x):

    • Nextcloud Hub 34 (AIO latest)

  • Operating system and version (e.g., Ubuntu 24.04):

    • Ubuntu Server 24.04 LTS

  • Web server and version (e.g, Apache 2.4.25):

    • Apache (Nextcloud AIO)

  • Reverse proxy and version _(e.g. nginx 1.27.2)

    • Caddy (Nextcloud AIO)

  • PHP version (e.g, 8.3):

    • PHP 8.4 (AIO default)

  • Is this the first time you’ve seen this error? (Yes / No):

    • Yes

    When did this problem seem to first start?

    • While migrating from Docker Socket Proxy to HaRP and attempting to prepare an external Docker deployment for AppAPI ExApps.

  • Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)

    • Nextcloud AIO

  • Are you using CloudfIare, mod_security, or similar? (Yes / No)

    • No

Summary of the issue you are facing:

I am trying to understand whether HaRP in Nextcloud AIO fully supports external Docker engines via FRP, or if additional configuration is required.

After enabling the optional HaRP container in AIO:

  • AppAPI automatically created the harp_aio daemon
  • Test Deploy succeeds
  • test-deploy ExApp deploys successfully
  • nextcloud-aio-harp is healthy
  • nc_app_test-deploy is healthy

However I noticed that the HaRP container does not publish any ports on the Docker host.

docker port nextcloud-aio-harp

returns nothing.

docker inspect nextcloud-aio-harp --format='{{json .HostConfig.PortBindings}}'

returns:

{}

Inside the container I can see:

0.0.0.0:8780 LISTEN (haproxy)
:::8782 LISTEN (frps)

and from the Docker bridge network:

curl http://172.18.0.7:8780

returns:

HTTP/1.1 404 Not Found

which proves HaRP is responding internally.

However from the host:

curl http://HOST_IP:8780

returns:

Connection refused

My question is:

Is this expected behavior in AIO?

If so, how is a remote Docker engine expected to connect to the FRP endpoint on port 8782 when nextcloud-aio-harp does not expose any ports on the host?

I am not reporting a bug yet; I am trying to understand whether this is expected design, a missing configuration step, or a current limitation of the AIO HaRP integration.

Steps to replicate it (hint: details matter!):

  1. Deploy Nextcloud AIO
  2. Enable “HaRP (High-availability Reverse Proxy for Nextcloud ExApps)”
  3. Restart AIO containers
  4. Verify AppAPI daemon creation
  5. Run “Test Deploy” from AppAPI
  6. Inspect nextcloud-aio-harp networking

Relevant output:

docker inspect nextcloud-aio-harp --format=‘{{json .HostConfig.PortBindings}}’

{}

docker exec nextcloud-aio-harp netstat -tulpn

tcp 0 0 0.0.0.0:8780 LISTEN haproxy
tcp 0 0 :::8782 LISTEN frps

curl http://172.18.0.7:8780

HTTP/1.1 404 Not Found

curl http://HOST_IP:8780

Connection refused

2

Hi, can you check AIO 12.9.1 Beta / HaRP migration: old ExApps left behind, GUI stuck, manual recovery steps? Maybe this provides some guidance for you

3

Hi, yes I ran these commands to ensure there were no leftover artifacts from the NC34 migration. While investigating, I noticed that the nextcloud-aio-harp container does not seem reachable from the LAN.

When I register an external HaRP daemon, I correctly get the “connection successful” message, and during the test‑deploy the container appears on my remote Docker engine. But as soon as the liveness check begins, HAProxy bans the IP of the Nextcloud Apache container.

It feels like an internal routing or proxying issue: Apache relays the request, but HAProxy interprets it as invalid traffic and blocks it.

I tested FRP with and without TLS, and the result is always identical. Sorry for m’y english, i’m french IT.

4

I’m having trouble converting like this also. Before the move to the new harp container, I had already spent weeks trying to get the HARP (host) version working before the AIO version was released. I got it working, too, but it was messy, and so I hope the AIO version will be cleaner.

But some notes from the manual install of host harp — we had to get the FRP up and running (the goal was to run an exapp on a separate machine from the main nextcloud) and this also required having an entry in the reverse proxy for my external web interface. The reverse proxy (for me, NGINX) had to have a specific custom setup that pointed /exapps to the right place.

Also, the harp container needed to be exposed to the host nextwork. It was all working, but unfortunately the exapp itself wasn’t working well (context chat) so I’m trying this new approach and getting stuck.

5

Hi everyone,

After analyzing the Nextcloud AIO php/containers.json file with the help of multiple AIs/LLMs, here is the raw technical breakdown of why the native nextcloud-aio-harp configuration cannot perform remote or automatic multi-host orchestration.

1. Hardcoded Read-Only Docker Socket

In the AIO architecture, the Docker socket is mounted into the HaRP container with write permissions explicitly disabled:

"volumes": [
  {
    "source": "%WATCHTOWER_DOCKER_SOCKET_PATH%",
    "destination": "/var/run/docker.sock",
    "writeable": false
  }
]
6

Hi,

I would like to report a reproducible issue with HaRP when Nextcloud is running under Nextcloud AIO.
Below is a summary of the tests performed and the exact behavior observed.

Environment

  • Nextcloud AIO (latest as of June 2026)

  • HaRP server running externally on a separate host (M720q)

  • HaRP worker running externally on another host (P520)

  • Both hosts connected through Tailscale

  • Both HaRP server and worker deployed using the official image:
    ghcr.io/nextcloud/nextcloud-appapi-harp:release

What works

1. HaRP server (FRPS) starts correctly

  • Ports 8780 and 8782 are listening on the host.

  • TLS certificates are generated.

  • FRPS logs show normal startup.

2. HaRP worker (FRPC) connects successfully to the HaRP server

Worker logs show:

Code

login to server success
proxy added: [bundled-deploy-daemon]
start proxy success

This confirms that FRPC → FRPS communication works correctly.

3. Test‑deploy container starts correctly on the worker

During a test‑deploy initiated from Nextcloud AIO, the worker logs show:

Code

[test-deploy] start proxy success
Uvicorn running on unix socket /tmp/exapp.sock

This confirms that the test‑deploy container is created and running on the worker.

What fails

4. Nextcloud AIO cannot validate the test‑deploy

Even though the worker successfully starts the test‑deploy container and the FRP tunnel is established, Nextcloud AIO reports the test as failed.

Worker logs show repeated errors during the validation phase:

Code

connect to server error: stream closed
connect to server error: EOF

This happens before the successful FRPC login, and again after the test‑deploy container starts.

5. Nextcloud AIO cannot reach the external HaRP server

The FRPS logs show no incoming validation request from Nextcloud AIO during the test‑deploy.

This suggests that the AIO environment cannot reach the external FRPS endpoint (<tailscale-ip>:8782) during the validation step.

Additional test: LAN-only setup

To rule out VPN or routing issues, we repeated the entire setup on local LAN only, without Tailscale.

  • HaRP server reachable on LAN IP

  • HaRP worker reachable on LAN IP

  • FRPC connects successfully

  • Test‑deploy container starts successfully

  • Nextcloud AIO still fails the validation step in the exact same way

The same errors appear:

Code

connect to server error: stream closed
connect to server error: EOF

This confirms that the issue is not related to Tailscale, not related to VPN, and not related to routing.
The behavior is identical on a pure LAN environment.

Summary

  • External HaRP server works.

  • External HaRP worker works.

  • FRP tunnel works.

  • Test‑deploy container starts correctly on the worker.

  • Only the validation step fails, because Nextcloud AIO cannot reach the external HaRP server, even on LAN.

This behavior appears to be specific to Nextcloud AIO, likely due to its internal Docker network isolation.

If you need additional logs (FRPS, FRPC, test‑deploy container, or Nextcloud logs), I can provide them.

Thank Copilot 365 + Gemini :stuck_out_tongue:

7

Hi, I have a question regarding the “Caddy with geoblocking” community container; I think the HaRP worker is unable to reach url /exapps/app_api.

8

If you are using a proxy, try entering the following information; it might help.

location /exapps/ {

        proxy_pass http://<interne IP>:8780; # interne IP-Adresse des Docker-Server

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

    }
9

Ok few minutes later ^^, i trie ingest proxy exapps in caddy community by caddy imports without succes. I think the imports is in root webserver (ambiguous site definition: https://) .If you see all-in-one/Containers/apache/Caddyfile at main · nextcloud/all-in-one · GitHub , this is HaRP (ExApps)

route /exapps/* {
reverse_proxy {$HARP_HOST}:8780
}

And not here aio-caddy/start.sh at main · szaimen/aio-caddy · GitHub

10

These settings don’t go into the AIO Caddy instance either!

They need to be configured in the root web server or the reverse proxy located in front of your web server.

So, at the same point where you point your web address to your web server or server.