build(docker): add Dockerfile for building a server image

[almirb]

Multi-stage build: compiles aw-webui and aw-server, then ships only the release binary on debian:bookworm-slim with libssl3.

Only aw-server is built, not aw-sync: on Linux the latter pulls in openssl with the "vendored" feature and compiles OpenSSL from source, which is not needed by the image.

[greptile-apps]

Unverified installer controls build artifacts

When the floating NodeSource endpoint is compromised, intercepted, or changed unexpectedly, its response executes directly as root in the builder stage and can modify the server or web assets copied into the runtime image, causing the published image to contain unreviewed code. How this was verified: The remote response runs before make aw-server in the same builder stage whose outputs are copied into the final image.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Server runs as root

The runtime stage has no USER directive, so the documented network-facing server and its datastore operations run as UID 0; this unnecessarily expands the impact of a process compromise and creates root-owned files on bind-mounted storage. How this was verified: The final stage launches aw-server-rust without changing users, and the application does not drop privileges.

[greptile-apps]

Greptile Summary

Adds a containerized build and runtime path for aw-server-rust.

• Adds a multi-stage Dockerfile that builds aw-webui and the release server binary.
• Adds Docker build-context exclusions.
• Documents image construction, networking, persistence, and architecture targeting.

Confidence Score: 3/5

The PR should not merge until the builder stops executing unverified remote installer content that can modify the shipped image.

The NodeSource response runs as root in the same stage that produces artifacts copied into the final image, while the runtime also unnecessarily retains root privileges.

Files Needing Attention: Dockerfile

Security Review

The build executes an unverified remote installer with control over shipped artifacts, and the resulting network-facing service runs as root.

Important Files Changed

Filename	Overview
Dockerfile	Adds the complete image build and runtime flow, but executes an unverified remote installer and runs the final service as root.
.dockerignore	Excludes generated build, dependency, coverage, and local-tool artifacts from the Docker context.
README.md	Documents the Docker workflow and correct persistent datastore path, while reinforcing the image's root-user runtime assumptions.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart LR
    S[Repository checkout] --> B[Rust builder image]
    N[NodeSource setup script] --> B
    B --> W[Build aw-webui]
    W --> R[Build release aw-server]
    R --> I[Debian runtime image]
    I --> C[Run aw-server on port 5600]
    V[(Persistent datastore volume)] --> C

Loading

_{Reviews (1): Last reviewed commit: "build(docker): add Dockerfile for buildi..." | Re-trigger Greptile}

[ErikBjare]

We have rejected similar PRs in the past, as the Dockerfiles aren't being used by maintainers or in CI and so not something we want to maintain or bless/suggest we support.

If you explain your usecase I might change my mind.

[almirb]

We have rejected similar PRs in the past, as the Dockerfiles aren't being used by maintainers or in CI and so not something we want to maintain or bless/suggest we support.

If you explain your usecase I might change my mind.

Fair enough — I understand not wanting to bless or maintain something you
don't use. Let me describe the use case, and also scope down what I'm
actually asking for.

Use case: I run aw-server-rust as an always-on central instance on a
headless Ubuntu server, aggregating data from [N] machines that sync into
it. This is essentially the setup aw-sync's README already describes (a
central instance + multidevice query), just permanent rather than a
temporary testing instance. On a headless server managed by Portainer,
a container is the natural unit of deployment — there is no aw-qt, no
desktop session, no user systemd unit to hang it off.

Why this might matter to the project: the absence of a Dockerfile
doesn't mean people don't run this in Docker — it means they run someone
else's image. I was pulling brain40/aw-server-rust:latest from Docker
Hub for months: an opaque binary, built by a stranger, from unknown
source, handling all of my activity data. For a project whose entire
value proposition is privacy and data ownership, pushing self-hosters
toward unauditable third-party images seems like the worse outcome. A
Dockerfile in-tree lets people build it themselves and verify what they
run.

What I'm not asking for: no official image on Docker Hub, no release
pipeline, no support promise, no badge in the README. Just the build
recipe in-tree.

To address the maintenance concern, I'm happy to do any of:

• Mark it explicitly as community-contributed and unsupported in the
  README, so it carries no implication of official support.
• Put it under contrib/ instead of the repo root.

One thing the containerized build surfaced, incidentally: make build
fails in a clean environment because aw-sync pulls in openssl with the
vendored feature (#478) and compiles OpenSSL from source. My Dockerfile
sidesteps it by building only the aw-server target. A clean-room build
tends to expose this kind of friction that a developer machine hides.

If the answer is still no, that's completely fine — I'll keep it in my
fork. In that case, would you be open to a line in the docs pointing to
community-maintained images? That's zero maintenance for you and still
better than people finding random images on Docker Hub.

That's a very nice project! Congrats!