Not able to create a login account after fresh install using Docker Compose

[trharmon0]

See subject. There error message is simply : "[object Object]" near the top of the "Create an account" dialog.

I'm using the default Docker Compose manifest and env file with the following changes:

• changed front-end exposed port to tcp/4000 to avoid collision with another service on the Docker host.
• set the various passwords in the env file using pwgen output.

The docker logs output of the frontend container is:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get "http://%2Fvar%2Frun%2Fdocker.sock/v1.47/containers/f9649fcde3a0/json": dial unix /var/run/docker.sock: connect: permission denied

The hosting platform is TrueNAS:

 System Version: 25.04.2.6 

PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

The Compose stack was deployed using Dockge installed as a TrueNAS containerized app.

https://github.com/truenas/apps/tree/master/ix-dev/community/dockge

[Polliog]

Hi @angelics,

Apologies for the late response, I usually monitor issues on the main repository and missed this discussion.

This is the same issue reported in #52. The [object Object] error you're seeing is the "Failed to Fetch" error being displayed incorrectly.

Root cause: The frontend was defaulting to localhost:8080 for API calls, which doesn't work when accessing LogWard remotely – your browser tries to connect to your local machine instead of the server.

The fix: We've implemented auto-detection of the API URL. When you access the frontend on a non-standard port (like your :4000), it will automatically detect the backend at same-host:8080.

You can test the fix now using the release candidate:

Pull the test images

  docker pull logward/frontend:0.3.2-rc1
  docker pull logward/backend:0.3.2-rc1

Or in your .env / docker-compose:

  LOGWARD_FRONTEND_IMAGE=logward/frontend:0.3.2-rc1
  LOGWARD_BACKEND_IMAGE=logward/backend:0.3.2-rc1

Let me know if this resolves your issue!

[Polliog]

We resolved this problem in the v0.3.2

[trharmon0]

Still seeing the object error on attempt to create an account. Perhaps I need to get the environment variable which specifies the URL to the frontend as in the other ticket?

[Polliog]

If the frontend can't reach the backend yes

[boku42]

Dear all,

I am facing the same "Failed to Fetch" error in my first time deployment with version 0.4.1. I also went through the discussion or error #52.
I use Caddy reverse proxy for a self-hosted installation of frontend and backend with https://logtide.<example.com>. I understood that the client needs to have direct access to the backend.

So, what does that mean for a setup with a reverse proxy? If PUBLIC_API_URL in .env is not set, it would use thttps://logtide.<example.com> with docker-internal port 8080 or with the mapped port 61243 ("61243:8080")? So, should the PUBLIC_API_URL be overwritten like https://logtide.<example.com>:?

thanks

[Polliog]

Hi, the configuration is that in PUBLIC_API_URL you set the URL of the backend. For example, if you have the backend on https://api.logtide.dev, the .env will be:

PUBLIC_API_URL=https://api.logtide.dev

Don't include Docker's mapped ports (like :61243) in PUBLIC_API_URL. Your reverse proxy (Caddy) handles the routing from the public URL to the internal Docker port.

of course you can use also the path so for example https://logtide.example.com/api (this will also be the url in PUBLIC_API_URL)
in this case make sure your Caddyfile routes both frontend and backend correctly. For example:

   logtide.example.com {
       handle /api/* {
           reverse_proxy backend:8080
       }
       handle {
           reverse_proxy frontend:3000
       }
   }

[boku42]

Thank you very much! It seems, I got one step further - now I get "Unauthorized" and in the log I see:

logtide-backend   | 2026-01-18T08:54:28.788959763Z {"level":30,"time":1768726468788,"pid":1,"hostname":"fc8bfca11e93","reqId":"req-c","req":{"method":"GET","url":"/api/api/v1/auth/providers","hostname":"logtide.example.com","remoteAddress":"<IP_of_docker_network_gateway>","remotePort":44000},"msg":"incoming request"}

logtide-backend   | 2026-01-18T08:54:28.790262357Z {"level":30,"time":1768726468790,"pid":1,"hostname":"fc8bfca11e93","reqId":"req-c","res":{"statusCode":401},"responseTime":1.2472639679908752,"msg":"request completed"}

I assume, it is related to the API secret? I have the following in my .env:
API_KEY_SECRET=<32_long_secret>

Can you please share how a curl command could look like that includes the API secret for testing? Or is it related to something else?

[Polliog]

The api key secret is used for the generation of the JWT, you can generete an api key from the project settings
example:

curl -X POST https://api.logtide.dev/api/v1/ingest   -H "X-API-Key: lp_your_api_key_here"   -H "Content-Type: application/json"   -d '{
    "logs": [{
      "time": "2025-01-23T10:30:00Z",
      "service": "my-app",
      "level": "info",
      "message": "Hello from LogTide Cloud!"
    }]
  }'

more info https://logtide.dev/docs/