Add a Docker image for the web instance

[FixFever]

problem description

Information about selfhosting a web app has been removed from the manual.
https://github.com/imputnet/cobalt/blob/main/docs/run-an-instance.md
The old configuration now runs 2 instances of cobalt-api.

How to selfhost new version of web app?

your instance configuration

  cobalt_api:
    image: ghcr.io/imputnet/cobalt:latest
    container_name: cobalt_api
    ports:
      - 9002:9000/tcp
    environment:
      - API_URL=https://api.cobalt.${DOMAIN}/
    restart: unless-stopped
      
  cobalt:
    image: ghcr.io/imputnet/cobalt:latest
    container_name: cobalt
    ports:
      - 9003:9001/tcp
    environment:
      - WEB_URL=https://cobalt.${DOMAIN}/
      - API_URL=https://api.cobalt.${DOMAIN}/
    restart: unless-stopped

[Write]

They answered me in Discord: You can't as of right now.

You'd have to set your own instances (API) in this : https://cobalt.tools/settings/instances

I personally stay on v7 for now, waiting (hopefully) to have someone create a docker-compose for the web facing interface.

[JakeyPrime]

Web must be run manually right now, but it does exist in the web directory, it's just not containerized.

[wukko]

You can't as of right now.

who said that? you can host it as a static build (the same way we do). you can read everything you need to know in web's readme file: https://github.com/imputnet/cobalt/blob/main/web/README.md

[Write]

You can't as of right now.

who said that? you can host it as a static build (the same way we do). you can read everything you need to know in the web's readme file.

Not as a docker compose, I meant.

[wukko]

it is also indeed better to use the main web app with your api instance: https://cobalt.tools/settings/instances

we don't track anything and it's one less thing for you to take care of.

[wukko]

Not as a docker compose, I meant.

i don't think we'll be providing a docker image for frontend for now. if that ever changes, i'll try to remember to let you know.

[spectrapulse]

I'm unsure why it was appropiate to go this route especially considering that this was provided before without issue.

Would you consider a PR adding this back?

[dumbmoron]

Would you consider a PR adding this back?

hey, sure! if you would like to work on it, here is a general outline of how i'd envision for it to look:

• the dockerfile would be configurable during build time using the same environment variables as listed in the web readme. it wouldn't have any runtime environment variables (since they wouldn't have any effect anyways)
• the final docker image would ideally have no node.js runtime, and would just contain the build output + some lightweight web server like nginx:alpine
• it would use the same dockerfile for caching as recommended in pnpm documentation

[spectrapulse]

Would you consider a PR adding this back?

hey, sure! if you would like to work on it, here is a general outline of how i'd envision for it to look:

• the dockerfile would be configurable during build time using the same environment variables as listed in the web readme. it wouldn't have any runtime environment variables (since they wouldn't have any effect anyways)
• the final docker image would ideally have no node.js runtime, and would just contain the build output + some lightweight web server like nginx:alpine
• it would use the same dockerfile for caching as recommended in pnpm documentation

The last two points should be straightforward to implement.

The first point, however, could be tricky. It’s inconvenient to have to republish a self-built variant to another registry—especially if you're using Kubernetes or Docker Swarm. Keeping it up-to-date would also be a hassle, and it rules out tools like Watchtower unless you're hosting your own fork with changes.

I'm unsure of the best approach here, but maybe providing an additional image variant alongside the static web server image or just going the node image route with a reverse proxy like NGINX in front of node could work better.

If we do want to go with the static webserver route I might take inspiration from how Piped handles this in their frontend, but this wouldn't solve issues with environment variables other than WEB_HOST and WEB_DEFAULT_API for users who want to integrate Plausible or Turnstile. This would also be the most jank approach.

[dumbmoron]

@spectrapulse

[...] or just going the node image route with a reverse proxy like NGINX in front of node could work better.

one of the goals when rewriting the frontend was for it to be relatively small and simple to host from the server perspective (no processing required to serve frontend pages post-build), which unfortunately comes at the cost of runtime customizability (and i guess is also one of the reasons why there is no "official" dockerfile for it right now).

but if we once again bundle the entirety of the node project with the image (node_modules for web is ~100 MB on my machine) we are basically back to square 1, so that's why i wouldn't really consider this option to be "right" (in comparison, the static build output is just under 30 MB, and also vite mentions in their documentation explicitly not to use preview as a production server)

If we do want to go with the static webserver route I might take inspiration from how Piped handles this in their frontend, but this wouldn't solve issues with environment variables other than WEB_HOST and WEB_DEFAULT_API for users who want to integrate Plausible or Turnstile. This would also be the most jank approach.

i don't think this would work here since cobalt also uses these envs to include/omit certain parts of components (like hiding text that is not relevant if plausible is not enabled).

maybe one approach (that i'm not sure how feasible would be) would be to build the frontend at startup and then get rid of the whole build environment and just serve the static files, which isn't really ideal, but it would work i guess

[ggtylerr]

In case anyone needs a docker image right now, I've made a basic one here: https://github.com/ggtylerr/globe/blob/master/services/cobalt-template/Dockerfile Do note that the copy paths would need to be changed if you aren't using the repo. It's just a matter of changing two lines.

It's probably not suitable for a PR but in case it's used as a base, I've addressed some of the points @dumbmoron made:

• It simply uses ARG instead of environment variables. While this isn't suitable for any published images, it's straightforward when building (which we'll have to do anyways at this time.)
• For simplicity's sake this Dockerfile uses http-server but it could probably be modified for nginx.
• It's only for the web app at the moment but it could very easily be merged with the existing app Dockerfile.