Inaccessible when running in Docker Compose (Portainer)

[gthvidsten]

I have created the following Docker Compose file:

services:
  seq:
    image: 'datalust/seq:2025'
    container_name: seq
    restart: unless-stopped
    ports:
      - '5341:5341'
    volumes:
      - /mnt/seq:/data
    environment:
      ACCEPT_EULA: 'Y'
      SEQ_API_CANONICALURI: 'https://my.domain/seq/'
      SEQ_FIRSTRUN_ADMINPASSWORD: 'MyPassword'
    networks:
      - nginx
networks:
  nginx:
    name: nginx
    external: true

And everything seemingly starts up just fine with the following in the console log:

────────────────────────────────────────
  Seq ♦ Machine data, for humans.
─────────── © 2025 Datalust Pty Ltd ────
Running as server; press Ctrl+C to exit.
[11:37:14 INF] Seq 2025.2.15055 running on OS Ubuntu 22.04.5 LTS
[11:37:14 INF] Seq listening on ["http://localhost/", "https://localhost/", "http://localhost:5341/", "https://localhost:45341/"]
[11:37:14 INF] Seq using canonical URI https://my.domain/seq/
[11:37:14 INF] Opening event store at /data/Stream/stream.flare
[11:37:15 INF] Opening metastore /data/Documents/metastore.flare
[11:37:15 INF] Initializing a new metastore
[11:37:15 INF] Enabling username/password authentication, and using the supplied default admin password
[11:37:15 INF] Creating default workspace for user-admin
[11:37:16 INF] Storage subsystem available
[11:37:16 INF] Storing new key key-2bcd63ad-6520-4a9f-8ca0-e189e537141d
[11:37:16 INF] Loaded key xmlkey-18 with friendly name key-2bcd63ad-6520-4a9f-8ca0-e189e537141d
[11:37:16 INF] Ingestion enabled

However, when accessing http://<Server-IP>:5341 or through my reverse proxy on https://my.domain/seq I only get a 404 response with the following body:

{"Error":"Not found."}

What am I missing here? It seems like this is a pretty basic setup, so I feel like I must be missing something very simple.

Also, seeing as the same error is returned both for the reverse proxy and accessing it directly I don't think it is the reverse proxy's fault (and the reverse proxy works for several other sites).

[mloskot]

TL;TR: Seq UI and API listens on port 80

Long answer, replace 5341:5341 with 5341:80, as it is presented in the docker run command at https://datalust.co/docs/docker-deployment-overview, then http://localhost:5341 will get you the UI as well as this health probe will respond as expected:

$ curl http://localhost:5341/health
{"status":"healthy","description":"The Seq node is in service."}

Alternatively, or even better, just publish 80 on 80:

    ports:
    - "80:80/tcp"  # API, UI

then both, Seq UI and API will be accessible:

• http://localhost:80/api/
• http://localhost:80/health

Publishing 5341:5431 like you did above or displayed here:

    ports:
    - "80:80/tcp" # UI, API
    - "5341:5341/tcp" # Ingestion

means publishing the ingestion port, what the Seq configuration confirms too

$ docker container exec seq cat /data/Seq.json | head -n 25
{
  "api": {
    "ingestionPorts": [
      5341,
      45341
    ],
    "canonicalUri": null,
...
    "ingestionPort": null,
    "listenUris": [
      "http://localhost:80",
      "https://localhost:443",
      "http://localhost:5341",
      "https://localhost:45341"
    ],

The container log line

[17:16:29 INF] Seq listening on ["http://localhost/", "https://localhost/", "http://localhost:5341/", "https://localhost:45341/"]

may be confusing suggesting that both, localhost:80 and localhost:5431, are equivalent, but they are not :)

[gthvidsten]

Thanks for the reply, and you are absolutely correct that the I assumed both to be correct! :)

Does that mean I should expose both 80 and 5341 in my reverse proxy, or can loggers also use 80 so that I only have to care about that?

[gthvidsten]

I see... I think...
When I've set up Seq with the SEQ_API_CANONICALURI config, does this only have an effect on the API/UI, or does it also affect ingestion? In other words, can I set up ingestion to use http://<ServerIp>:5341 and still access the UI on https://my.domain/seq, or have I now introduced a conflict where ingestion must also use http://my.domain:5341/seq (which will go through Nginx and I don't want to have to manage that specific port in Nginx)?

[mloskot]

When I've set up Seq with the SEQ_API_CANONICALURI config, does this only have an effect on the API/UI, or does it also affect ingestion?

My understanding of api.canonicalUri and Set a Canonical URI is that it affects all URLs which are generated by Seq on Seq UI or in Seq API responses.

However, I deploy Seq with Docker as well as to Kubernetes cluster and I have never set the api.canonicalUri setting.
In case of Docker, I have not used any proxy though.
In case of the Kubernetes, I simply use the official Helm chart and configure values of the UI and Ingestion ingresses:

ingestion:
  ingress:
    enabled: true
    hosts:
    - seq.example.com
    path: /ingestion
ui:
  ingress:
    enabled: true
    hosts:
    - seq.example.com
    path: /dashboard

which then, Kubernetes ingress supports only HTTP/HTTPS ports, are translated to path-based routing of incoming traffic to cluster gateway port 80 or 443 to Seq services listening on UI and ingestion ports:

• http://seq.example.com/dashboard maps to Seq container at port 80
• http://seq.example.com/ingestion maps to Seq container at port 5341

I guess, you can do similar in your Docker setup with NGINX proxy, either do path-based routing similar as above or host-based routing, for example:

• dashboard.my.domain to Seq container at port 80
• ingestion.my.domain to Seq container at port 5341

This should allow you avoid use of raw IP:PORT and access Seq services via NGINX proxy.

[gthvidsten]

I guess this means that the 404 I got in my OP was actually the ingest endpoint not being invoked correctly? And that I can set up something similar to what you have with https://my.domain/seq/dashboard being forwarded to port 80 and https://my.domain/seq/ingestion being forwarded to port 5341, and then having any services I create just use https://my.domain/seq/ingestion as their endpoint (on port 443) and not having to worry about 5341 ever again?

Also, since you say you don't use the canonicalUri setting then maybe I can remove my environment variable and these endpoints should still work?

[mloskot]

I guess this means that the 404 I got in my OP was actually the ingest endpoint not being invoked correctly?

Yes

then having any services I create just use https://my.domain/seq/ingestion as their endpoint (on port 443) and not having to worry about 5341 ever again?

Yes. Your proxy forwards the requests to Seq port(s) as well as handles TLS termination (in case you hit your proxy at 443).

maybe I can remove my environment variable and these endpoints should still work?

AFAICT, yes.

In case of deploying Seq to Kubernetes, the official Helm chart provides baseURI setting which is directly mapped to SEQ_API_CANONICALURI variable.
I can confirm that I don't set the baseURI for any of my deployments, that is, I don't set api.canonicalUri and I'm fine with it :)
(I don't use Azure Entra ID/OIDC authentication, where that would be required to generate correct URLs for redirects.)

[gthvidsten]

I'm actually using OIDC authentication, so maybe I need to have the canonicalUrl set. Hopefully I can add an "ingress" to port 5341 on another path and it'll work even if it's not the same "canonical" URL as the ingress and UI are two different things. I'll experiment more tomorrow (and during the coming week).

Thank you so much for your replies. They have been very helpful in furthering my understanding in how the various endpoints behave :)

[mloskot]

I'm actually using OIDC authentication, so maybe I need to have the canonicalUrl set.

s/maybe I need/I have to/ ;) as per the docs https://datalust.co/docs/openid-connect saying: "If Seq is behind a proxy or load balancer, you must also set SEQ_API_CANONICALURI ..."

But, as I said, I don't use it myself, so I can't tell anything for sure.

Thank you so much for your replies.

I'm happy to help.

[mloskot]

@gthvidsten By the way, on the Seq behind proxy with SEQ_API_CANONICALURI, you may want to have a look at this thread in #2502 (reply in thread) and watch

• https://github.com/datalust/seq-tickets/issues/2503

as there may be some issues.

[liammclennan]

@mloskot those links only apply to Seq.Api and seqcli.