🚀 Feature: Docker containers of each component (backend & frontend) #402

New Issue

OVERLORD · 2025-10-09T16:44:26+03:00

OVERLORD commented

2025-10-09 16:44:26 +03:00

Originally created by @wargio on GitHub.

Feature description

It would be nice to have pocket-id:latest-frontend & pocket-id:latest-backend for more advance users.

Pitch

Currently i'm running the frontend and the backend without caddy by overwriting the entrypoint.sh script (this is to avoid having 2 reverse proxy in chain). this is a bit hacky and having just two images for each component would be great.

Originally created by @wargio on GitHub. ### Feature description It would be nice to have `pocket-id:latest-frontend` & `pocket-id:latest-backend` for more advance users. ### Pitch Currently i'm running the frontend and the backend without caddy by overwriting the entrypoint.sh script (this is to avoid having 2 reverse proxy in chain). this is a bit hacky and having just two images for each component would be great.

OVERLORD added the feature label 2025-10-09 16:44:26 +03:00

OVERLORD closed this issue

2025-10-09 16:44:27 +03:00

OVERLORD commented

2025-10-09 16:44:31 +03:00

@wargio commented on GitHub:

This is exactly what i do and i just disable caddy from running, since i don't need it.

services:
  pocket-id:
    image: registry.domain.local/stonith404/pocket-id:latest
    container_name: pocket-id
    environment:
      - PUID=1000
      - PGID=1000
      - PUBLIC_APP_URL=https://sso.domain.local
      - MAXMIND_LICENSE_KEY=
      - DB_PROVIDER=sqlite
      - HOST=0.0.0.0
    ports:
      - 127.0.0.1:12673:3000 # pocket-id frontend
      - 127.0.0.1:12674:8080 # pocket-id backend
    volumes:
      - ./data:/app/backend/data
      - ./entrypoint.sh:/app/scripts/docker/entrypoint.sh:ro
    restart: unless-stopped
    logging:
      driver: "json-file"
      options:
        max-size: "10m"

and the entrypoint.sh

echo "Starting frontend..."
node frontend/build &

echo "Starting backend..."
cd backend && ./pocket-id-backend &

wait

@wargio commented on GitHub: This is exactly what i do and i just disable caddy from running, since i don't need it. ```yaml services: pocket-id: image: registry.domain.local/stonith404/pocket-id:latest container_name: pocket-id environment: - PUID=1000 - PGID=1000 - PUBLIC_APP_URL=https://sso.domain.local - MAXMIND_LICENSE_KEY= - DB_PROVIDER=sqlite - HOST=0.0.0.0 ports: - 127.0.0.1:12673:3000 # pocket-id frontend - 127.0.0.1:12674:8080 # pocket-id backend volumes: - ./data:/app/backend/data - ./entrypoint.sh:/app/scripts/docker/entrypoint.sh:ro restart: unless-stopped logging: driver: "json-file" options: max-size: "10m" ``` and the `entrypoint.sh` ```bash echo "Starting frontend..." node frontend/build & echo "Starting backend..." cd backend && ./pocket-id-backend & wait ```

OVERLORD commented

2025-10-09 16:44:32 +03:00

@kmendell commented on GitHub:

@wargio I think the way svelte works is it has to be compilied , so im not sure that would be possible, unless we would release that standalone image, will ahve to defer to stonith though...

@kmendell commented on GitHub: @wargio I think the way svelte works is it has to be compilied , so im not sure that would be possible, unless we would release that standalone image, will ahve to defer to stonith though...

OVERLORD commented

2025-10-09 16:44:33 +03:00

@stonith404 commented on GitHub:

In my personal projects, I use separate images for the frontend and backend. However, for projects like this, I prefer a single image because it simplifies the installation process and reduces potential setup issues.

@wargio, couldn’t you just expose the backend and frontend ports directly from the container? Caddy would still run, but you’d be bypassing it.

I also agree with @kmendell’s opinion. For advanced users, building the image themselves likely wouldn’t be a problem.

@stonith404 commented on GitHub: In my personal projects, I use separate images for the frontend and backend. However, for projects like this, I prefer a single image because it simplifies the installation process and reduces potential setup issues. @wargio, couldn’t you just expose the backend and frontend ports directly from the container? Caddy would still run, but you’d be bypassing it. I also agree with @kmendell’s opinion. For advanced users, building the image themselves likely wouldn’t be a problem.

OVERLORD commented

2025-10-09 16:44:34 +03:00

@kmendell commented on GitHub:

Hi @wargio You can build the backend / frontend manually and use those or push your own docker image, I think the idea is to keep it simple for users, so for more advanced users I think that may be the approach we should take, @stonith404 do you agree?

If you follow the Standalone installation docs, that will get you the build steps required for what I'm describing above.

Though i do see what you are asking for and could see how it's useful as well.

@kmendell commented on GitHub: Hi @wargio You can build the backend / frontend manually and use those or push your own docker image, I think the idea is to keep it simple for users, so for more advanced users I think that may be the approach we should take, @stonith404 do you agree? If you follow the Standalone installation docs, that will get you the build steps required for what I'm describing above. Though i do see what you are asking for and could see how it's useful as well.

OVERLORD commented

2025-10-09 16:44:36 +03:00

@wargio commented on GitHub:

I think the best solution would be to have a static webui (kinda like you have when compile React) and serve it from Golang GIN framework, so we can avoid running node for some static files, so in this way you don't need caddy to reverse proxy anything and the users can avoid having 2 reverse proxies in chain for no reasons.

@wargio commented on GitHub: I think the best solution would be to have a static webui (kinda like you have when compile React) and serve it from Golang GIN framework, so we can avoid running node for some static files, so in this way you don't need caddy to reverse proxy anything and the users can avoid having 2 reverse proxies in chain for no reasons.

OVERLORD commented

2025-10-09 16:44:38 +03:00

@wargio commented on GitHub:

have you make any performance tests to determine if chaining two reverse proxies has a significant impact?

there is no real performance difference. just cached resources vs live pages.

Would a acceptable solution to this be to create some documentation on how to build the containers? For these "advanced users" or should we leave it as is?

Absolutely. maybe we could modify the entrypoint to disable caddy via env variable, so advance users can setup their reverse proxy in whatever flavour they want.

@wargio commented on GitHub: > have you make any performance tests to determine if chaining two reverse proxies has a significant impact? there is no real performance difference. just cached resources vs live pages. > Would a acceptable solution to this be to create some documentation on how to build the containers? For these "advanced users" or should we leave it as is? Absolutely. maybe we could modify the entrypoint to disable caddy via env variable, so advance users can setup their reverse proxy in whatever flavour they want.

OVERLORD commented

2025-10-09 16:44:38 +03:00

@wargio commented on GitHub:

@wargio I think you can already do this by using the following in docker compose:
entrypoint: ["/bin/bash", "entrypoint.sh"]

No. The entrypoint script needs to be replaced with one calling the needed binaries. So I either use two instances which calls the binaries directly via entrypoint/cmd or replace the script. Both requires to know the binary name, so if in the future this change it will break the deployment of some people. It's safer to just modify the entry point for everybody and support an environment variable which launches or not caddy.

@wargio commented on GitHub: > @wargio I think you can already do this by using the following in docker compose: > > ```yaml > entrypoint: ["/bin/bash", "entrypoint.sh"] > ``` No. The entrypoint script needs to be replaced with one calling the needed binaries. So I either use two instances which calls the binaries directly via entrypoint/cmd or replace the script. Both requires to know the binary name, so if in the future this change it will break the deployment of some people. It's safer to just modify the entry point for everybody and support an environment variable which launches or not caddy.

OVERLORD commented

2025-10-09 16:44:39 +03:00

@stonith404 commented on GitHub:

Exporting the frontend as static HTML and JS is technically possible but would require disabling server-side features currently in use. For instance, most pages rely on server-side rendering.

I think removing server side rendering might actually worsen the performance more than having two reverse proxies. @wargio, have you make any performance tests to determine if chaining two reverse proxies has a significant impact?

@stonith404 commented on GitHub: Exporting the frontend as static HTML and JS is technically possible but would require disabling server-side features currently in use. For instance, most pages rely on server-side rendering. I think removing server side rendering might actually worsen the performance more than having two reverse proxies. @wargio, have you make any performance tests to determine if chaining two reverse proxies has a significant impact?

OVERLORD commented

2025-10-09 16:44:41 +03:00

@kmendell commented on GitHub:

@wargio @stonith404 Would a acceptable solution to this be to create some documentation on how to build the containers? For these "advanced users" or should we leave it as is?

@kmendell commented on GitHub: @wargio @stonith404 Would a acceptable solution to this be to create some documentation on how to build the containers? For these "advanced users" or should we leave it as is?

OVERLORD commented

2025-10-09 16:44:43 +03:00

@kmendell commented on GitHub:

@wargio I think you can already do this by using the following in docker compose:

entrypoint: ["/bin/bash", "entrypoint.sh"]

@kmendell commented on GitHub: @wargio I think you can already do this by using the following in docker compose: ```yaml entrypoint: ["/bin/bash", "entrypoint.sh"] ```

OVERLORD commented

2025-10-09 16:44:44 +03:00

@stonith404 commented on GitHub:

In v0.29.0 Caddy can now be disabled with DISABLE_CADDY=true.

@stonith404 commented on GitHub: In `v0.29.0` Caddy can now be disabled with `DISABLE_CADDY=true`.

OVERLORD referenced this issue

2025-10-09 16:58:05 +03:00

[PR #402] [MERGED] refactor: do not include test controller in production builds #832

Sign in to join this conversation.