Heartbeat check not working

[melroy89]

Describe the bug

Deployments are running 100%, however AppAPI is unable to check for heartbeat, test deployment also works, but the health check fails.

Nextcloud is running on the same machine as Docker (localhost).

Steps/Code to Reproduce

• Admin settings
• AppAPI
• Do a test deployment

Expected Results

• Heath check just work fine

Actual Results

• Heath check fails, while the test deploy container is actually running fine.

docker ps looks like this:

CONTAINER ID   IMAGE                                            COMMAND                  CREATED          STATUS                    PORTS                                                                        NAMES
2d99315d324b   ghcr.io/nextcloud/test-deploy:release            "python3 main.py"        53 seconds ago   Up 53 seconds (healthy)                                                                                nc_app_test-deploy
2b2a232b7148   ghcr.io/nextcloud/nextcloud-appapi-dsp:release   "/bin/bash start.sh"     5 minutes ago    Up 5 minutes (healthy)    0.0.0.0:2375->2375/tcp                                                       nextcloud-appapi-dsp

SO actually docker ps shows HEALTHY. While Nextcloud is unable to retrieve a heartbeat for the container?

https://docs.nextcloud.com/server/latest/admin_manual/exapps_management/TestDeploy.html#heartbeat

And yes the docker image is running on the same host as Nextcloud. But of course this test will fail, if you do not expose any default port (as you can see port is fully empty) for the container ghcr.io/nextcloud/test-deploy

Or what should I have configured differently? The nextcloud log says:

ExApp test-deploy heartbeat check failed. Make sure that Nextcloud instance and ExApp can reach it other. 

Executing manually via curl: http://<IP>:2375/v1.41/containers/nc_app_test-deploy/json, gives me the following info:

{
  "Id": "8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9",
  "Created": "2025-02-24T22:39:49.307729551Z",
  "Path": "python3",
  "Args": [
    "main.py"
  ],
  "State": {
    "Status": "running",
    "Running": true,
    "Paused": false,
    "Restarting": false,
    "OOMKilled": false,
    "Dead": false,
    "Pid": 1651461,
    "ExitCode": 0,
    "Error": "",
    "StartedAt": "2025-02-24T22:39:49.366452662Z",
    "FinishedAt": "0001-01-01T00:00:00Z",
    "Health": {
      "Status": "healthy",
      "FailingStreak": 0,
      "Log": [
        {
          "Start": "2025-02-24T23:39:59.646730071+01:00",
          "End": "2025-02-24T23:39:59.693247989+01:00",
          "ExitCode": 0,
          "Output": ""
        },
        {
          "Start": "2025-02-24T23:40:01.693955365+01:00",
          "End": "2025-02-24T23:40:01.735665635+01:00",
          "ExitCode": 0,
          "Output": ""
        },
        {
          "Start": "2025-02-24T23:40:03.73642847+01:00",
          "End": "2025-02-24T23:40:03.777381136+01:00",
          "ExitCode": 0,
          "Output": ""
        },
        {
          "Start": "2025-02-24T23:40:05.77822757+01:00",
          "End": "2025-02-24T23:40:05.820010528+01:00",
          "ExitCode": 0,
          "Output": ""
        },
        {
          "Start": "2025-02-24T23:40:07.820645332+01:00",
          "End": "2025-02-24T23:40:07.85454394+01:00",
          "ExitCode": 0,
          "Output": ""
        }
      ]
    }
  },
  "Image": "sha256:6c053cc15a3e5eb3293fadcb55efa894f42511ea7300592571f39157924d31e8",
  "ResolvConfPath": "/media/data_extra/docker/231072.231072/containers/8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9/resolv.conf",
  "HostnamePath": "/media/data_extra/docker/231072.231072/containers/8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9/hostname",
  "HostsPath": "/media/data_extra/docker/231072.231072/containers/8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9/hosts",
  "LogPath": "/media/data_extra/docker/231072.231072/containers/8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9/8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9-json.log",
  "Name": "/nc_app_test-deploy",
  "RestartCount": 0,
  "Driver": "overlay2",
  "Platform": "linux",
  "MountLabel": "",
  "ProcessLabel": "",
  "AppArmorProfile": "docker-default",
  "ExecIDs": null,
  "HostConfig": {
    "Binds": null,
    "ContainerIDFile": "",
    "LogConfig": {
      "Type": "json-file",
      "Config": {}
    },
    "NetworkMode": "docker_socket_proxy_external_network",
    "PortBindings": null,
    "RestartPolicy": {
      "Name": "unless-stopped",
      "MaximumRetryCount": 0
    },
    "AutoRemove": false,
    "VolumeDriver": "",
    "VolumesFrom": null,
    "ConsoleSize": [
      0,
      0
    ],
    "CapAdd": null,
    "CapDrop": null,
    "CgroupnsMode": "private",
    "Dns": null,
    "DnsOptions": null,
    "DnsSearch": null,
    "ExtraHosts": null,
    "GroupAdd": null,
    "IpcMode": "private",
    "Cgroup": "",
    "Links": null,
    "OomScoreAdj": 0,
    "PidMode": "",
    "Privileged": false,
    "PublishAllPorts": false,
    "ReadonlyRootfs": false,
    "SecurityOpt": null,
    "UTSMode": "",
    "UsernsMode": "",
    "ShmSize": 67108864,
    "Runtime": "runc",
    "Isolation": "",
    "CpuShares": 0,
    "Memory": 0,
    "NanoCpus": 0,
    "CgroupParent": "",
    "BlkioWeight": 0,
    "BlkioWeightDevice": null,
    "BlkioDeviceReadBps": null,
    "BlkioDeviceWriteBps": null,
    "BlkioDeviceReadIOps": null,
    "BlkioDeviceWriteIOps": null,
    "CpuPeriod": 0,
    "CpuQuota": 0,
    "CpuRealtimePeriod": 0,
    "CpuRealtimeRuntime": 0,
    "CpusetCpus": "",
    "CpusetMems": "",
    "Devices": null,
    "DeviceCgroupRules": null,
    "DeviceRequests": null,
    "MemoryReservation": 0,
    "MemorySwap": 0,
    "MemorySwappiness": null,
    "OomKillDisable": null,
    "PidsLimit": null,
    "Ulimits": null,
    "CpuCount": 0,
    "CpuPercent": 0,
    "IOMaximumIOps": 0,
    "IOMaximumBandwidth": 0,
    "Mounts": [
      {
        "Type": "volume",
        "Source": "nc_app_test-deploy_data",
        "Target": "/nc_app_test-deploy_data"
      }
    ],
    "MaskedPaths": [
      "/proc/asound",
      "/proc/acpi",
      "/proc/kcore",
      "/proc/keys",
      "/proc/latency_stats",
      "/proc/timer_list",
      "/proc/timer_stats",
      "/proc/sched_debug",
      "/proc/scsi",
      "/sys/firmware",
      "/sys/devices/virtual/powercap"
    ],
    "ReadonlyPaths": [
      "/proc/bus",
      "/proc/fs",
      "/proc/irq",
      "/proc/sys",
      "/proc/sysrq-trigger"
    ]
  },
  "GraphDriver": {
    "Data": {
      "ID": "8ef505495b22b048cdabc9a0e81cf06a9aa0a4abe8ea4c95281e2ad1f3decbe9",
      "LowerDir": "/media/data_extra/docker/231072.231072/overlay2/b9a6a42f12a1f062ce247879300276bc87741987285d319722bb0dbed0458755-init/diff:/media/data_extra/docker/231072.231072/overlay2/d3e860c07e5c9e656786ad1a59f0b9f9e943cfe73ee94c633fe6c81efa444171/diff:/media/data_extra/docker/231072.231072/overlay2/e9ffde5569f1337d984fc8a07be9d56cbd0bd193d5962d94e3db941dd6613021/diff:/media/data_extra/docker/231072.231072/overlay2/a503f62ebf567592dd5f1c67e85c581726138f26a85883f10ad777668070bc0c/diff:/media/data_extra/docker/231072.231072/overlay2/a1d9da86f829a4e6e6159ad772c943d0fe2a8ac29fe9041eb7999e51393322b9/diff:/media/data_extra/docker/231072.231072/overlay2/8870c9b64d27dea095f7daa21652d10667bf900315134769a7a7eed4f5b607b3/diff:/media/data_extra/docker/231072.231072/overlay2/cc53ae637ba99beecff0500730e8a677afdc820231d6934544d111a79a615073/diff:/media/data_extra/docker/231072.231072/overlay2/7784c6bf5226e072ec4e7b693deb5ed13836d3b02f63b4c0f672d98b764fcded/diff:/media/data_extra/docker/231072.231072/overlay2/671281dccadc6978573ab9e56e8cb7a423689ffd18c314f8011699f710e0f961/diff:/media/data_extra/docker/231072.231072/overlay2/70ecb42739e218e1ec4444b9445dd7e032ebbbcf00e7708d921024041eb7cd6e/diff:/media/data_extra/docker/231072.231072/overlay2/cfa6674c0ff3d803f89f9993f7ca5ffde33dde94ff89ddfe7e90e1bee72bb407/diff:/media/data_extra/docker/231072.231072/overlay2/1860a66bd577044a1ab34ce6397b2679aecfb0bb4dab29eead838014d66fa01b/diff:/media/data_extra/docker/231072.231072/overlay2/fc354d559182916057a39fdce5b467525b69935d09219aa75bca6ca6ca848007/diff:/media/data_extra/docker/231072.231072/overlay2/596a9b7771709e20967d10205be487bff5a10dfa75dca58cc2699991f2e61ae4/diff:/media/data_extra/docker/231072.231072/overlay2/71881ac229c2cfd1ac2603664f0403c1cf91931af4b5636690af393e9bde42f1/diff:/media/data_extra/docker/231072.231072/overlay2/770c08d2c2dcfd27354e123df3c99f756884c132472ba2d20f90ecc06eeb5fcd/diff",
      "MergedDir": "/media/data_extra/docker/231072.231072/overlay2/b9a6a42f12a1f062ce247879300276bc87741987285d319722bb0dbed0458755/merged",
      "UpperDir": "/media/data_extra/docker/231072.231072/overlay2/b9a6a42f12a1f062ce247879300276bc87741987285d319722bb0dbed0458755/diff",
      "WorkDir": "/media/data_extra/docker/231072.231072/overlay2/b9a6a42f12a1f062ce247879300276bc87741987285d319722bb0dbed0458755/work"
    },
    "Name": "overlay2"
  },
  "Mounts": [
    {
      "Type": "volume",
      "Name": "nc_app_test-deploy_data",
      "Source": "/media/data_extra/docker/231072.231072/volumes/nc_app_test-deploy_data/_data",
      "Destination": "/nc_app_test-deploy_data",
      "Driver": "local",
      "Mode": "z",
      "RW": true,
      "Propagation": ""
    }
  ],
  "Config": {
    "Hostname": "test-deploy",
    "Domainname": "",
    "User": "",
    "AttachStdin": false,
    "AttachStdout": false,
    "AttachStderr": false,
    "Tty": false,
    "OpenStdin": false,
    "StdinOnce": false,
    "Env": [
      "AA_VERSION=4.0.6",
      "APP_SECRET=ZID08bqhEH1n4sNJ0ggT1DVqKHi5JEyqQpdO60TsXX+umCO3ny8BFCiPGwMewPHvjVLTSPCnDyujQTqMLk5ghMZ+Afy8gMg46P/qlWXb7WJuE2QLoNtg5PPtIwT6AC+C",
      "APP_ID=test-deploy",
      "APP_DISPLAY_NAME=TestDeploy",
      "APP_VERSION=1.1.0",
      "APP_HOST=0.0.0.0",
      "APP_PORT=23001",
      "APP_PERSISTENT_STORAGE=/nc_app_test-deploy_data",
      "NEXTCLOUD_URL=<secret>",
      "COMPUTE_DEVICE=CPU",
      "PATH=/usr/local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
      "LANG=C.UTF-8",
      "GPG_KEY=A035C8C19219BA821ECEA86B64E628F8D684696D",
      "PYTHON_VERSION=3.11.11",
      "PYTHON_SHA256=2a9920c7a0cd236de33644ed980a13cbbc21058bfdc528febb6081575ed73be3"
    ],
    "Cmd": null,
    "Healthcheck": {
      "Test": [
        "CMD-SHELL",
        "/healthcheck.sh"
      ],
      "Interval": 2000000000,
      "Timeout": 2000000000,
      "Retries": 300
    },
    "Image": "ghcr.io/nextcloud/test-deploy:release",
    "Volumes": null,
    "WorkingDir": "/ex_app/lib",
    "Entrypoint": [
      "python3",
      "main.py"
    ],
    "OnBuild": null,
    "Labels": {}
  },
  "NetworkSettings": {
    "Bridge": "",
    "SandboxID": "982afd10a8bdbb31b02ac112d4e1688964b1656fd9b03874d9f38dfe391efcb2",
    "SandboxKey": "/var/run/docker/netns/982afd10a8bd",
    "Ports": {},
    "HairpinMode": false,
    "LinkLocalIPv6Address": "",
    "LinkLocalIPv6PrefixLen": 0,
    "SecondaryIPAddresses": null,
    "SecondaryIPv6Addresses": null,
    "EndpointID": "",
    "Gateway": "",
    "GlobalIPv6Address": "",
    "GlobalIPv6PrefixLen": 0,
    "IPAddress": "",
    "IPPrefixLen": 0,
    "IPv6Gateway": "",
    "MacAddress": "",
    "Networks": {
      "docker_socket_proxy_external_network": {
        "IPAMConfig": null,
        "Links": null,
        "Aliases": [
          "test-deploy",
          "8ef505495b22"
        ],
        "MacAddress": "2e:ec:6a:64:a5:ef",
        "DriverOpts": null,
        "GwPriority": 0,
        "NetworkID": "1b79bfdb1db441180ad6c43c833e59e2736d50c8ecf99d341bc80697c87dba47",
        "EndpointID": "9fff88a70f529492f41dd89fb563f24baac36b078515b19ef1fdb60bbc784955",
        "Gateway": "10.254.10.129",
        "IPAddress": "10.254.10.132",
        "IPPrefixLen": 25,
        "IPv6Gateway": "",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "DNSNames": [
          "nc_app_test-deploy",
          "test-deploy",
          "8ef505495b22"
        ]
      }
    }
  }
}

So what is the problem?

How does Nextcloud AppAPI check the container heartbeat? Why would it fail in my case? Since the docker containers are running fine!

Setup configuration

• Nextcloud Hub 9 (30.0.6)
• AppAPI v4.0.6
• Docker version 28.0.0, build f9ced58
• Linux ubuntu-server 6.8.0-53-generic #55-Ubuntu SMP PREEMPT_DYNAMIC Fri Jan 17 15:37:52 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

[oleksandr-nc]

But of course this test will fail, if you do not expose any default port (as you can see port is fully empty)

It should work without exposing ports.

Does ping works from your host machine?

ping nc_app_test-deploy ?

Did you create not a default bridge network for the ExApps? Default bridged network in docker does not support DNS

[melroy89]

Uhm I see. I indeed get Name or service not known with ping. So AppAPI is using ping using the docker appname to check for a heartbeat?

I have a secure Docker setup, and it's recommended to setup dedicated network in Docker (and not using the default docker network or even the host network is normally not recommended at all).

Could you please document this here: https://docs.nextcloud.com/server/latest/admin_manual/exapps_management/DeployConfigurations.html#docker-deploy-daemon

You're right I'm using a bridge network (I can't use the host network since I use "userns-remap": "default" for security reasons).

So this is how my docker compose now looks like:

services:
  docker-socket-proxy:
    userns_mode: host
    restart: always
    image: ghcr.io/nextcloud/nextcloud-appapi-dsp:release
    container_name: nextcloud-appapi-dsp
    privileged: true
    networks:
      - socket_proxy_external_network
    ports:
      - "127.0.0.1:2375:2375"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - NC_HAPROXY_PASSWORD=<secret_password>

networks:
  socket_proxy_external_network:

But like I said before, could you please document the requirements of the docker network for AppAPI?

Also I run Unbound DNS server on the server, so please document the requirements better.

Since I'm using Unbound the systemd resolved has the following config:

[Resolve]
DNS=127.0.0.1
DNSSEC=yes
DNSStubListener=no
Domains=home

I run a lot of Docker containers already without any issues, but it is good to know that Nextcloud AppAPI is using the Docker container name as the "hostname".

[melroy89]

Of there it .. all way at the bottom: "In all other cases, the ExApp should be available by it’s name: e.g. when using docker custom bridge network all containers available by DNS."

Can some additional info be provided maybe? Or link to this section from the "Docker Deploy Daemon" section...

[melroy89]

Since the docker image is just running fine on localhost:ex_app_port, how can I keep the custom Docker network name while also configuring $deployConfig['net'] to host, so AppAPI will try to reach localhost instead?

If I somehow could set internally $deployConfig['net'] to host or at least $exAppHost = 'localhost';, but still keep using my Docker network bridge that would be ideal I think, again the docker contain is running fine, but AppAPI should allow me to use localhost:ex_app_port for the heartbeat check.

And no, I can't just use host network that will give me errors deploying new Docker containers:

Client error: `POST http://127.0.0.1:2375/v1.41/containers/create?name=nc_app_test-deploy` resulted in
a `400 Bad Request` response: {"message":"cannot share the host's network namespace when user namespaces are enabled"} 

Because the Docker setup is hardened like userns-remap": "default" (for security reasons) I did set userns_mode: host in docker compose though (see below this example):

{
  "experimental": false,
  "icc": false,
  "userns-remap": "default",
  "storage-driver": "overlay2",
  "userland-proxy": false,
  "live-restore": false,
  "no-new-privileges": true,
  "dns": ["1.1.1.1", "208.67.222.222", "8.8.8.8"],
  "ipv6": false,
  "ip6tables": false,
  "fixed-cidr-v6": "2a02:22a0:bbba:f900::/64",
  "registry-mirrors": ["http://127.0.0.1:6000"],
  "insecure-registries": ["127.0.0.1:6000"],
  "data-root": "/media/data_extra/docker",
  "bip": "10.254.1.1/24",
  "default-address-pools":[
    {"base":"10.254.0.0/16","size":25}
  ]
}

Together with:

services:
  docker-socket-proxy:
    userns_mode: host
    restart: always
    image: ghcr.io/nextcloud/nextcloud-appapi-dsp:release
    container_name: nextcloud-appapi-dsp
    privileged: true
    networks:
      - socket_proxy_external_network
    ports:
      - "127.0.0.1:2375:2375"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    environment:
      - NC_HAPROXY_PASSWORD=<secret>

networks:
  socket_proxy_external_network:

---

Hence I follow the following Docker Socket Proxy setup using the "Docker Socket Proxy" with "Docker Socket Proxy should be deployed with network=bridge" option.

That is also why I use 127.0.0.1:2375 as the Daemon host in AppAPI in Nextcloud.

ExApps Log content is of the test deploy is:

Started
INFO:     Started server process [1]
INFO:     Waiting for application startup.
TRACE:    ASGI [1] Started scope={'type': 'lifespan', 'asgi': {'version': '3.0', 'spec_version': '2.0'}, 'state': {}}
TRACE:    ASGI [1] Receive {'type': 'lifespan.startup'}
TRACE:    ASGI [1] Send {'type': 'lifespan.startup.complete'}
INFO:     Application startup complete.
INFO:     Uvicorn running on http://0.0.0.0:23001 (Press CTRL+C to quit)

It should work without exposing ports.

Basically I want to deploy on my protected bridge network in Docker and expose the ports. Then use localhost / 127.0.0.1 to access the Docker deployments.

And the same should then apply for other container like windmill / flow should not only expose 8000 TCP (which is by default now exposed?) but also port 23001 (or port 24000 or whatever).

[gitwittidbit]

I'm also stuck at this point.

The Connection check is successful, the test app successfully is deployed. But my NC can't get the heartbeat. This is so frustrating (after many unsuccessful attempts to get ExApps working on my main NC, I set up a new NC just to figure this out and, for the life of me, I can't...)

Given that AI is now an integral part of NC, setting this up shouldn't be so complicated.

[gitwittidbit]

From the NC docs:

Heartbeat

The Heartbeat step checks if the container’s health check is finished and the container is healthy. The ExApp might have additional pre-configuration logic during this step.

Possible errors:

ExApp failed to start a web server, e.g., if the port is already in use (this should be visible in the container logs)

ExApp heartbeat_count keeps increasing, this may indicate that the ExApp couldn’t start properly

Nextcloud can not reach the ExApp container, e.g.,

        due to a network issue or a firewall (this should be visible in the server logs or the firewall logs)

        due to a “http” protocol deploy daemon. In this case, the ExApp’s container listens on localhost (127.0.0.1 or ::1) which might not be reachable from the Nextcloud server and you might want to listen on a different IP address. See OVERRIDE_APP_HOST in [Additional options](https://docs.nextcloud.com/server/latest/admin_manual/exapps_management/ManagingDeployDaemons.html#additional-options-list) in the Deploy Daemon form. This issue can be identified using this command: lsof -i -P -n | grep LISTEN

What does this even mean?

I believe that I could have a "http" protocol daemon. At least, I needed to supply the VM's IP address together with the port (2375) to get the connection test working.

But which one is the ExApp container? The proxy container? Well, this is the one that appears to be reachable. Or the test app container? That one says that it is listening on 0.0.0.0 (and not on 127.0.0.1).

Can some explain what the docs are trying to say here?

[melroy89]

Look; you are not alone, I also needed to read their documentation page I think 10 times (no bs).

Well, they forgot to mention there are many many other reasons why heartbeat might not work...

Like, in the case if your Docker setup (like my setup) is not allowed to create containers on the host network (aka --net=host ) directly.
Which is in fact dangerous anyway... Like I mentioned above, good sys admins will not allow this, and harden their Docker setup! Meaning you can not use --net=host due to security reasons! Meaning whatever NC invented should not be used in production environments.

Don't believe me, instead read the official docs: https://docs.docker.com/engine/security/userns-remap/
Crazy right!? I know.. I still would like to get a response from Nextcloud on my previous comment above.

Another reason could be that the container host name is not resolvable, because well again if you are unable to leverage the host network, docker won't use the built-in embedded DNS server (Docker is basically using the Moby libnetwork network stack for this). There might be an issue to resolve your container name to an IP address.

So regarding your question.. Ignore OVERRIDE_APP_HOST, these settings are only relevant if you are deploying on another server/network different from where you are running your Nextcloud server. So I assume you are also running Docker on the same machine as where you are running your Nextcloud instance, right? In that case ignore those last 2 bullet points from the documentation.

[tstreibl]

I have the same problem (fail at heartbeat check) under nextcloud 30.0.6. After upgrading to nextcloud 31.0.2 the integration test already fails at the beginning saying: "Fehler beim Starten der Installation von ExApp". The protocol says: "{"error":"ExApp nicht gefunden, Protokolle konnten nicht abgerufen werden"}". I didn't change anything in the settings and the connection test during registration was successful. I run nextcloud from the docker community edition behind traefik as a reverse proxy. I use "nextcloud-appapi-dsp:2375" as hostname and "host" for the network to connect to the nextcloud-appapi-dsp service.

Log from the "EX-APP-Scelett" container, the connection test is starting (called "test-deploy"):

HP_SHARED_KEY is not set. Skipping FRP configuration. Starting main application... Started INFO: Started server process [1] INFO: Waiting for application startup. TRACE: ASGI [1] Started scope={'type': 'lifespan', 'asgi': {'version': '3.0', 'spec_version': '2.0'}, 'state': {}} TRACE: ASGI [1] Receive {'type': 'lifespan.startup'} TRACE: ASGI [1] Send {'type': 'lifespan.startup.complete'} INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:23000 (Press CTRL+C to quit) INFO: Shutting down INFO: Waiting for application shutdown. TRACE: ASGI [1] Receive {'type': 'lifespan.shutdown'} TRACE: ASGI [1] Send {'type': 'lifespan.shutdown.complete'} TRACE: ASGI [1] Completed INFO: Application shutdown complete. INFO: Finished server process [1] HP_SHARED_KEY is not set. Skipping FRP configuration. Starting main application... Started INFO: Started server process [1] INFO: Waiting for application startup. TRACE: ASGI [1] Started scope={'type': 'lifespan', 'asgi': {'version': '3.0', 'spec_version': '2.0'}, 'state': {}} TRACE: ASGI [1] Receive {'type': 'lifespan.startup'} TRACE: ASGI [1] Send {'type': 'lifespan.startup.complete'} INFO: Application startup complete. INFO: Uvicorn running on http://127.0.0.1:23000 (Press CTRL+C to quit)

Searching for "HP_SHARED_KEY" lead me to https://github.com/nextcloud/HaRP. Is there another way to install the AppAPI?

I wish they would integrate the AppAPI into the docker community edition as well, as they did for the docker-all-in-one version. It's the basis for all new features like workflows, ExApps, .... As a non expert I'm lost in configuration hell. Feels like maintaining Nextcloud becomes more and more difficult, kicking out the normal user.

[oleksandr-nc]

Like, in the case if your Docker setup (like my setup) is not allowed to create containers on the host network (aka --net=host ) directly.
Which is in fact dangerous anyway... Like I mentioned above, good sys admins will not allow this, and harden their Docker setup! Meaning you can not use --net=host due to security reasons! Meaning whatever NC invented should not be used in production environments.

Using host network is only needed when the ExApp is located on the remote server.
And ExApp in this case will bind only "127.0.0.1" interface, which is fully safe.

HaProxy will bind the external interface and will proxy the requests to the internal interface.
And it will check the credentials and perfom autoban if it is needed.

Searching for "HP_SHARED_KEY" lead me to https://github.com/nextcloud/HaRP. Is there another way to install the AppAPI?

Yes, this is a successor of the DockerSocketProxy for Nextcloud 32. It works for remote deployments without --host networks and allows ExApps to use websockets.
It should be much easier to configure and use, but it is only will be avalaible from Nextcloud 32.

For those who can't get AppAPI working at the moment, we hope that this will be a way out of the situation.

Regarding this topic - we will close it, please open topics on "Heartbeat check not working" separately with full list of actions you take to make it work and logs of Nextcloud and "Test Deploy", even if they are duplicates - or wait for Nextcloud 32, where everything should be much simpler.

I hope for your understanding, thank you all in advance.

[melroy89]

@oleksandr-nc sorry to ping you. But did you also read why my heart beat is not working? It's because I use a hardened docker setup and best practices. Actually everybody should hardened their docker setup and otherwise by default you can easily get hacked (trust me, I have been there). The default docker setup is not safe for production!

So the bottom line; nextcloud docker deployments are not working on a well configured & protected hardened docker setup. Where you are not allowed to have no new privileges, but more importantly set: "userns-remap": "default".

You have been warned your current nextcloud deployments are based on insecure docker practices. And might (and it will lead) to security issues on the server machine.

When will you support hardened docker setups? Maybe only remote deployments are production ready in terms of safe configurations?

[oleksandr-nc]

Actually everybody should hardened their docker setup and otherwise by default you can easily get hacked (trust me, I have been there). The default docker setup is not safe for production!

If you’re stating that the default setup is insecure, please clarify how it can be exploited from the outside, even theoretically.

You have been warned your current nextcloud deployments are based on insecure docker practices. And might (and it will lead) to security issues on the server machine.

However, it’s important to understand the context behind Docker practices—why they exist, what they are designed to protect against, and in which scenarios they truly matter. Labeling something as “not following best practices” is too broad and doesn’t always equate to a security flaw.

When will you support hardened docker setups? Maybe only remote deployments are production ready in terms of safe configurations?

As mentioned above, we’re introducing a new solution: HaRP—a successor to DockerSocketProxy. It’s designed to offer a more secure and flexible approach, supporting both current(except mapping to host network, it is very limited there and should be used in very rare custom cases) and broader configuration options.

[Tom60chat]

Just adding something: heartbeat check on AppAPI admin page when testing deployment, it's done inside your browser so make sure your browser can access the http(s)://harp_server:8780/exapps/app_api/docker/exapp/exists, you should get 401.
http(s)://harp_server should be in Nextcloud URL, on the frontend.
harp_server can be also, and should at the end be your nextcloud instance url, might need to add a reverse proxy rule.

Anyways, 'logging' on the admin page helps me to identify that issue.