feat(docker): added Docker to project #44

2026-01-19T20:20:20Z

oliverperzyk commented

2026-01-19 20:20:20 +00:00

(Migrated from github.com)

Added configuration for Docker Compose and Docker to run an instance of proxy much easier by using Docker's containers.

Summary by CodeRabbit

New Features
- Docker containerization support for simplified deployment and a prebuilt runtime image published via CI.
Chores
- Added local compose-based setup for easy testing.
- Added container build ignore patterns and linter ignore rules to reduce noisy warnings.
CI
- Integrated Docker linting into CI.
- Release workflow now builds and pushes Docker images alongside existing release artifacts.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

Note

Adds containerization and CI support for Docker alongside existing Go builds.

New Dockerfile and docker-compose.yaml to run the proxy (ports 19132/udp, mounts ./config), plus .dockerignore and .hadolint.yaml

Lint workflow now includes Dockerfile linting via Hadolint

Release workflow gains permissions and steps to build/tag/push images to GHCR using Buildx and docker/metadata-action while keeping binary release artifacts

^{Written by Cursor Bugbot for commit beeffe99cf. This will update automatically on new commits. Configure here.}

Added configuration for Docker Compose and Docker to run an instance of proxy much easier by using Docker's containers.  ## Summary by CodeRabbit * **New Features** * Docker containerization support for simplified deployment and a prebuilt runtime image published via CI. * **Chores** * Added local compose-based setup for easy testing. * Added container build ignore patterns and linter ignore rules to reduce noisy warnings. * **CI** * Integrated Docker linting into CI. * Release workflow now builds and pushes Docker images alongside existing release artifacts. ✏️ Tip: You can customize this high-level summary in your review settings.   --- > [!NOTE] > Adds containerization and CI support for Docker alongside existing Go builds. > > - New `Dockerfile` and `docker-compose.yaml` to run the proxy (ports `19132/udp`, mounts `./config`), plus `.dockerignore` and `.hadolint.yaml` > - Lint workflow now includes Dockerfile linting via Hadolint > - Release workflow gains permissions and steps to build/tag/push images to GHCR using Buildx and `docker/metadata-action` while keeping binary release artifacts > > Written by [Cursor Bugbot](https://cursor.com/dashboard?tab=bugbot) for commit beeffe99cf82392d572ea712234cdaae8172c0ed. This will update automatically on new commits. Configure [here](https://cursor.com/dashboard?tab=bugbot).

coderabbitai[bot] commented

2026-01-19 20:20:37 +00:00

(Migrated from github.com)

Note

Other AI code review bot(s) detected

CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.

📝 Walkthrough

Walkthrough

Adds containerization and Docker CI: a multi-stage Dockerfile, docker-compose service, .dockerignore, hadolint config, a Dockerfile lint job in CI, and Docker Buildx build-and-push steps in the release workflow.

Changes

Cohort / File(s)	Summary
Container images & runtime `Dockerfile`, `docker-compose.yaml`	Added a multi-stage Dockerfile (builder: `golang:1.24-alpine`, runtime: `alpine`) that compiles a static `gobds` binary and exposes UDP 19132; added `docker-compose.yaml` with `gobds-proxy` service, UDP port mapping, and host path mounts for config and resources.
CI: lint & release `.github/workflows/lint.yml`, `.github/workflows/release.yml`	Added a top-level `dockerfile` job to lint the Dockerfile with `hadolint`; extended release workflow to set up Docker Buildx, log in to `ghcr.io`, extract image metadata, and build & push the Docker image using the Dockerfile.
Lint config `.hadolint.yaml`	Added hadolint configuration ignoring rules `DL3007` and `DL3018`.
Docker context exclusions `.dockerignore`	Added `.dockerignore` excluding IDE dirs (`.idea`), `/mocks/`, root-level config files (`.toml`, `.json`, `.lock`), and executables (`.exe`) from Docker build contexts.

Sequence Diagram(s)

sequenceDiagram
  actor Dev as Developer
  participant GH as GitHub Actions
  participant Hadolint as Hadolint Action
  participant Buildx as Docker Buildx
  participant GHCR as ghcr.io

  Dev->>GH: push / open PR / create release
  GH->>Hadolint: run Dockerfile lint job
  Hadolint-->>GH: lint results
  GH->>Buildx: setup Buildx, build image (Dockerfile)
  Buildx->>GHCR: push image (tags/labels)
  GHCR-->>GH: push confirmation

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hop and build where code meets tin,
A tiny binary snug within.
Linted lines and CI hum,
Compose and images on the run—
A joyful hop, the release begins. 🚀

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately captures the main change: Docker support has been added to the project through Dockerfile, docker-compose.yaml, and related CI/CD configurations.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

> [!NOTE] > ## Other AI code review bot(s) detected > > CodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review.   <details> <summary>📝 Walkthrough</summary> ## Walkthrough Adds containerization and Docker CI: a multi-stage Dockerfile, docker-compose service, .dockerignore, hadolint config, a Dockerfile lint job in CI, and Docker Buildx build-and-push steps in the release workflow. ## Changes | Cohort / File(s) | Summary | |---|---| | **Container images & runtime** `Dockerfile`, `docker-compose.yaml` | Added a multi-stage Dockerfile (builder: `golang:1.24-alpine`, runtime: `alpine`) that compiles a static `gobds` binary and exposes UDP 19132; added `docker-compose.yaml` with `gobds-proxy` service, UDP port mapping, and host path mounts for config and resources. | | **CI: lint & release** `.github/workflows/lint.yml`, `.github/workflows/release.yml` | Added a top-level `dockerfile` job to lint the Dockerfile with `hadolint`; extended release workflow to set up Docker Buildx, log in to `ghcr.io`, extract image metadata, and build & push the Docker image using the Dockerfile. | | **Lint config** `.hadolint.yaml` | Added hadolint configuration ignoring rules `DL3007` and `DL3018`. | | **Docker context exclusions** `.dockerignore` | Added `.dockerignore` excluding IDE dirs (`.idea`), `/mocks/`, root-level config files (`*.toml`, `*.json`, `*.lock`), and executables (`*.exe`) from Docker build contexts. | ## Sequence Diagram(s) ```mermaid sequenceDiagram actor Dev as Developer participant GH as GitHub Actions participant Hadolint as Hadolint Action participant Buildx as Docker Buildx participant GHCR as ghcr.io Dev->>GH: push / open PR / create release GH->>Hadolint: run Dockerfile lint job Hadolint-->>GH: lint results GH->>Buildx: setup Buildx, build image (Dockerfile) Buildx->>GHCR: push image (tags/labels) GHCR-->>GH: push confirmation ``` ## Estimated code review effort 🎯 3 (Moderate) | ⏱️ ~20 minutes ## Poem > 🐰 I hop and build where code meets tin, > A tiny binary snug within. > Linted lines and CI hum, > Compose and images on the run— > A joyful hop, the release begins. 🚀 </details>   <details> <summary>🚥 Pre-merge checks | ✅ 3</summary> <details> <summary>✅ Passed checks (3 passed)</summary> | Check name | Status | Explanation | | :----------------: | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Description Check | ✅ Passed | Check skipped - CodeRabbit’s high-level summary is enabled. | | Title check | ✅ Passed | The title accurately captures the main change: Docker support has been added to the project through Dockerfile, docker-compose.yaml, and related CI/CD configurations. | | Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. | </details> ✏️ Tip: You can configure your own custom pre-merge checks in the settings. </details>   --- Thanks for using [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=smell-of-curry/gobds&utm_content=44)! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. <details> <summary>❤️ Share</summary> - [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai) - [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai) - [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai) - [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code) </details> Comment `@coderabbitai help` to get the list of available commands and usage tips.

coderabbitai[bot] (Migrated from github.com) reviewed

2026-01-19 20:41:22 +00:00

coderabbitai[bot] (Migrated from github.com) left a comment

Actionable comments posted: 2

🤖 Fix all issues with AI agents

In `@docker-compose.yaml`:
- Around line 2-4: The Compose file uses an invalid service field "name" under
the "gobds" service; replace that key with "container_name" if you want to set
the container's explicit name (or remove it and set a top-level project name
instead). Edit the "gobds" service block (service identifier "gobds") to remove
the "name" key and add "container_name: gobds-proxy" when appropriate, noting
that using container_name will disable scaling for that service.

In `@Dockerfile`:
- Line 12: The Dockerfile uses an unpinned base image in the FROM instruction
("FROM alpine:latest") which triggers hadolint DL3007; update that FROM line to
use a specific, pinned Alpine tag (for example "alpine:3.23.2" or another
approved version) so builds are reproducible and the linter error is resolved.
Ensure you replace the exact token "FROM alpine:latest" in the Dockerfile with
the chosen versioned tag.

🧹 Nitpick comments (1)

Dockerfile (1)

14-21: Run the container as a non-root user.

Best practice is to drop root in the runtime image to reduce blast radius.

🔧 Suggested hardening

-FROM alpine:latest AS runner
+FROM alpine:latest AS runner

-RUN apk --no-cache add ca-certificates tzdata
+RUN apk --no-cache add ca-certificates tzdata \
+    && adduser -D -g '' appuser

 WORKDIR /app

-COPY --from=builder /build/gobds .
+COPY --from=builder --chown=appuser:appuser /build/gobds .

 EXPOSE 19132/udp
+USER appuser
 CMD ["./gobds"]

**Actionable comments posted: 2** <details> <summary>🤖 Fix all issues with AI agents</summary> ``` In `@docker-compose.yaml`: - Around line 2-4: The Compose file uses an invalid service field "name" under the "gobds" service; replace that key with "container_name" if you want to set the container's explicit name (or remove it and set a top-level project name instead). Edit the "gobds" service block (service identifier "gobds") to remove the "name" key and add "container_name: gobds-proxy" when appropriate, noting that using container_name will disable scaling for that service. In `@Dockerfile`: - Line 12: The Dockerfile uses an unpinned base image in the FROM instruction ("FROM alpine:latest") which triggers hadolint DL3007; update that FROM line to use a specific, pinned Alpine tag (for example "alpine:3.23.2" or another approved version) so builds are reproducible and the linter error is resolved. Ensure you replace the exact token "FROM alpine:latest" in the Dockerfile with the chosen versioned tag. ``` </details> <details> <summary>🧹 Nitpick comments (1)</summary><blockquote> <details> <summary>Dockerfile (1)</summary><blockquote> `14-21`: **Run the container as a non-root user.** Best practice is to drop root in the runtime image to reduce blast radius. <details> <summary>🔧 Suggested hardening</summary> ```diff -FROM alpine:latest AS runner +FROM alpine:latest AS runner -RUN apk --no-cache add ca-certificates tzdata +RUN apk --no-cache add ca-certificates tzdata \ + && adduser -D -g '' appuser WORKDIR /app -COPY --from=builder /build/gobds . +COPY --from=builder --chown=appuser:appuser /build/gobds . EXPOSE 19132/udp +USER appuser CMD ["./gobds"] ``` </details> </blockquote></details> </blockquote></details>

Dockerfile

					
				@ -0,0 +9,4 @@

				RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o gobds ./main.go

				FROM alpine:latest AS runner

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

hadolint DL3007 rule docker latest tag

💡 Result:

Hadolint rule DL3007 warns against using the Docker "latest" tag for base images. Message: "Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag." It exists because unpinned "latest" makes builds non-reproducible and can break when upstream images change. Fix: use a specific, versioned tag (e.g. FROM ubuntu:20.04 or FROM python:3.11-slim) instead of FROM ubuntu:latest or FROM python:latest. [1][2]

🌐 Web query:

Alpine Linux latest stable version production recommended 2025

💡 Result:

As of Jan 19, 2026 the recommended production release series is Alpine 3.23 — use the latest point release in that series (e.g., 3.23.2). [1][2]

Sources

Alpine Linux news/index (shows 3.23.2 released Dec 17, 2025). [1]
Alpine 3.23.0 release notes (3.23 is the v3.23 stable series). [2]

🏁 Script executed:

# Find Dockerfile and related CI configuration
find . -type f -name "Dockerfile" -o -name "*.yml" -o -name "*.yaml" | head -20

Repository: smell-of-curry/gobds

Length of output: 200

🏁 Script executed:

# Check if there's a hadolint configuration or CI workflow
find . -type f \( -name ".hadolint.yaml" -o -name "hadolint.yaml" -o -name "*hadolint*" \) 2>/dev/null

Repository: smell-of-curry/gobds

Length of output: 46

🏁 Script executed:

# Check the Dockerfile around line 12
cat -n ./Dockerfile | sed -n '8,16p'

Repository: smell-of-curry/gobds

Length of output: 306

🏁 Script executed:

# Check the lint workflow to see hadolint configuration
cat ./github/workflows/lint.yml

Repository: smell-of-curry/gobds

Length of output: 123

🏁 Script executed:

# Check the lint workflow with correct path
cat ./.github/workflows/lint.yml

Repository: smell-of-curry/gobds

Length of output: 799

Replace alpine:latest with a specific version tag to fix the hadolint DL3007 error.

The FROM alpine:latest on line 12 triggers DL3007, which is not ignored by your workflow (only DL3008 is ignored). Use FROM alpine:3.23.2 or a compatible pinned version instead to ensure reproducible builds and pass CI linting.

🤖 Prompt for AI Agents

In `@Dockerfile` at line 12, The Dockerfile uses an unpinned base image in the
FROM instruction ("FROM alpine:latest") which triggers hadolint DL3007; update
that FROM line to use a specific, pinned Alpine tag (for example "alpine:3.23.2"
or another approved version) so builds are reproducible and the linter error is
resolved. Ensure you replace the exact token "FROM alpine:latest" in the
Dockerfile with the chosen versioned tag.

_⚠️ Potential issue_ | _🟠 Major_ <details> <summary>🧩 Analysis chain</summary> 🌐 Web query: `hadolint DL3007 rule docker latest tag` 💡 Result: Hadolint rule DL3007 warns against using the Docker "latest" tag for base images. Message: "Using latest is prone to errors if the image will ever update. Pin the version explicitly to a release tag." It exists because unpinned "latest" makes builds non-reproducible and can break when upstream images change. Fix: use a specific, versioned tag (e.g. FROM ubuntu:20.04 or FROM python:3.11-slim) instead of FROM ubuntu:latest or FROM python:latest. [1][2] --- 🌐 Web query: `Alpine Linux latest stable version production recommended 2025` 💡 Result: As of Jan 19, 2026 the recommended production release series is Alpine 3.23 — use the latest point release in that series (e.g., 3.23.2). [1][2] Sources - Alpine Linux news/index (shows 3.23.2 released Dec 17, 2025). [1] - Alpine 3.23.0 release notes (3.23 is the v3.23 stable series). [2] --- 🏁 Script executed: ```shell # Find Dockerfile and related CI configuration find . -type f -name "Dockerfile" -o -name "*.yml" -o -name "*.yaml" | head -20 ``` Repository: smell-of-curry/gobds Length of output: 200 --- 🏁 Script executed: ```shell # Check if there's a hadolint configuration or CI workflow find . -type f \( -name ".hadolint.yaml" -o -name "hadolint.yaml" -o -name "*hadolint*" \) 2>/dev/null ``` Repository: smell-of-curry/gobds Length of output: 46 --- 🏁 Script executed: ```shell # Check the Dockerfile around line 12 cat -n ./Dockerfile | sed -n '8,16p' ``` Repository: smell-of-curry/gobds Length of output: 306 --- 🏁 Script executed: ```shell # Check the lint workflow to see hadolint configuration cat ./github/workflows/lint.yml ``` Repository: smell-of-curry/gobds Length of output: 123 --- 🏁 Script executed: ```shell # Check the lint workflow with correct path cat ./.github/workflows/lint.yml ``` Repository: smell-of-curry/gobds Length of output: 799 --- </details> **Replace `alpine:latest` with a specific version tag to fix the hadolint DL3007 error.** The `FROM alpine:latest` on line 12 triggers DL3007, which is not ignored by your workflow (only DL3008 is ignored). Use `FROM alpine:3.23.2` or a compatible pinned version instead to ensure reproducible builds and pass CI linting. <details> <summary>🤖 Prompt for AI Agents</summary> ``` In `@Dockerfile` at line 12, The Dockerfile uses an unpinned base image in the FROM instruction ("FROM alpine:latest") which triggers hadolint DL3007; update that FROM line to use a specific, pinned Alpine tag (for example "alpine:3.23.2" or another approved version) so builds are reproducible and the linter error is resolved. Ensure you replace the exact token "FROM alpine:latest" in the Dockerfile with the chosen versioned tag. ``` </details>

docker-compose.yaml

					
				@ -0,0 +1,13 @@

				services:

				  gobds:

				    container_name: gobds-proxy

				    build:

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

Docker Compose specification service name field valid container_name

💡 Result:

Yes — you can set a service’s container_name in Compose, but it must follow the Compose/ Docker container-name rules: pattern [a-zA-Z0-9][a-zA-Z0-9_.-]+ (starts with alnum, then alnum/underscore/dot/hyphen). If you set container_name the service cannot be scaled to >1 container (and names must be unique); container_name is ignored when deploying a stack in swarm mode. [1][2]

Sources:

Compose Specification — container_name pattern and scaling note. [1]
Docker Compose docs — container_name uniqueness / swarm behavior. [2]

🌐 Web query:

Docker Compose service "name" field invalid spec

💡 Result:

That error happens because the top-level "name" key is part of the newer Compose Specification (project name), and older/older-style parsers (classic docker‑compose / mismatched compose-file versions) reject unknown top-level properties. Fixes:

Run the newer Compose implementation that understands the spec: use the modern command "docker compose" (v2+), or upgrade to a compose implementation that implements the compose-spec. [1][2]
Or remove the top-level name and instead set the project name via COMPOSE_PROJECT_NAME or docker-compose -p . [2]
If you must keep using an older parser, avoid the top-level name (or ensure your compose-file targets the correct spec/version). See related discussion/issue. [3]

Sources: Compose Specification (name top-level) and Docker docs; related GitHub/StackOverflow threads. [1][2][3]

🌐 Web query:

Docker Compose service level properties fields name vs container_name specification

💡 Result:

Short answer

service name = the key in docker-compose.yml under services; used by Compose as the logical service identifier, for default container names (project_service_index), network aliases, environment variable prefixes, and Compose orchestration. [1][2]
container_name = optional field that sets an explicit container name for that service’s container; it overrides Compose’s generated name but prevents scaling beyond one container, is ignored by swarm/stack deploy, and must be unique. [1][2]

Important details

Default container name format = (managed by Compose). Use different project names (-p) to run same service names separately. [3]
If you set container_name Compose can’t create multiple replicas (scaling errors) and service discovery via other Compose behaviors still uses the service name on the network. [1][2]
In swarm/stack mode container_name is ignored; Swarm generates names differently. [1][2]

Sources

Docker Compose / Compose file reference (container_name, behavior). [1]
Compose Specification (services.container_name). [2]
Practical notes about Compose project/service naming and conflicts. [3]

🌐 Web query:

Docker Compose "name:" field service invalid properties allowed

💡 Result:

Short answer: Whether a top-level name: (or name: under networks/services) is allowed depends on which Compose schema/parser you’re using. The Compose specification (and Docker CLI "docker compose" v2 which implements it) accepts a top-level name field; the older docker‑compose (v1 Python tool) and some tools/validators still validate against older schemas and will report "Additional property 'name' is not allowed". Use the Compose v2 CLI (or a compose-spec‑aware parser) or remove/avoid that field for older parsers. [1][2][3]

What to do:

If you see "Additional property name is not allowed", run the file with the new CLI: docker compose (space) instead of docker‑compose, or upgrade to a compose-spec compliant tool. [1][3]
For networks: some compose schema versions don’t accept a networks..name entry; ensure you use a supported file version or the compose-spec. [1][4]

Sources:

Docker Compose file reference / services and compose spec. [1]
GitHub issues showing "name" added by docker compose v2 and older tools rejecting it. [2][4]
Stack Overflow explanation about compose-spec vs older docker‑compose tools. [3]

🌐 Web query:

Docker Compose service properties allowed fields reference documentation

💡 Result:

See the official Compose file reference (Docker Docs) for the full list of allowed service properties and details, and the Compose Specification for the canonical field definitions:

Docker Compose file reference — Services (allowed service fields, field descriptions and examples). [1]
Compose Specification — Services top-level element (canonical specification of service fields and behavior). [2]

If you want, I can list the most common service keys (image, build, ports, volumes, environment, networks, depends_on, deploy, secrets, configs, etc.) with brief descriptions and which Compose/engine versions support them.

🏁 Script executed:

#!/bin/bash
# Search for Docker Compose specification or file reference documentation online
# to find the canonical list of allowed service fields
curl -s "https://raw.githubusercontent.com/compose-spec/compose-spec/master/spec.md" | head -200 | grep -A 50 "## Services"

Repository: smell-of-curry/gobds

Length of output: 46

🌐 Web query:

Docker Compose service "name" property invalid not allowed specification

💡 Result:

You're seeing that error because the Compose file you're using contains a top-level or resource "name" key that your Compose implementation/schema/version doesn't accept.

Key points and fixes

The Compose file schema varies by tool/version (docker-compose v1, Docker Compose v2 plugin, docker stack). Some versions add a top-level name or accept resource-level name (networks, volumes); older tools or the swarm stack deploy schema reject that property. [1][2]
Quick fixes:
1. Remove the top-level name property from the generated/handwritten YAML (or remove unexpected resource-level name entries). This resolves validation for tools that disallow it. [2][5]
2. Use COMPOSE_PROJECT_NAME or docker compose --project-name (or docker-compose -p) instead of a top-level name. [1][4]
3. If you need resource names (e.g., networks.name), ensure your compose file version and the Compose binary support it — or upgrade Docker Compose to a recent v2 release that implements the newer schema. Matching the compose CLI to the file format version fixes many such errors. [1][3][7]

How to troubleshoot (quick)

Run docker compose version (or docker-compose version) to see which implementation you have. If it's the old python docker-compose, consider upgrading to the Compose V2 plugin. [1]
Validate with docker compose config (or docker-compose -f file config) and remove or adjust the offending name line per the tool's allowed keys. GitHub issues show the same error message when schema/version mismatches occur. [2][5]

References

Docker Compose services/file reference (compose file schema and sections). [1]
GitHub issues showing "'name' does not match any of the regexes" and "Additional property name is not allowed" when schema/tool mismatch occurs. [2][5]

🌐 Web query:

Compose specification service schema allowed fields list container_name

💡 Result:

Yes — container_name is a valid service field in the Compose specification. Key points:

Type: string (custom container name). [1][2]
Regex: SHOULD follow [a-zA-Z0-9][a-zA-Z0-9_.-]+. [1][2]
Effect: if container_name is set, Compose implementations MUST NOT (and Docker Compose will not) scale that service beyond one container — attempting to scale results in an error. [1][2]

Sources: Compose spec and Docker Compose docs. [1] https://compose-spec.github.io/compose-spec/05-services.html [2] https://docs.docker.com/compose/compose-file/05-services/

name is not a valid service field in Compose spec.

Use container_name to set an explicit container name for the service; alternatively, set a top-level name: for the project. Without this change, Compose validation will fail.

Note: Setting container_name prevents the service from being scaled to multiple containers.

Suggested fix

 services:
   gobds:
-    name: gobds-proxy
+    container_name: gobds-proxy

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

  gobds:
    container_name: gobds-proxy
    build:

🤖 Prompt for AI Agents

In `@docker-compose.yaml` around lines 2 - 4, The Compose file uses an invalid
service field "name" under the "gobds" service; replace that key with
"container_name" if you want to set the container's explicit name (or remove it
and set a top-level project name instead). Edit the "gobds" service block
(service identifier "gobds") to remove the "name" key and add "container_name:
gobds-proxy" when appropriate, noting that using container_name will disable
scaling for that service.

✅ Addressed in commit beeffe9

_⚠️ Potential issue_ | _🟠 Major_ <details> <summary>🧩 Analysis chain</summary> 🌐 Web query: `Docker Compose specification service name field valid container_name` 💡 Result: Yes — you can set a service’s container_name in Compose, but it must follow the Compose/ Docker container-name rules: pattern [a-zA-Z0-9][a-zA-Z0-9_.-]+ (starts with alnum, then alnum/underscore/dot/hyphen). If you set container_name the service cannot be scaled to >1 container (and names must be unique); container_name is ignored when deploying a stack in swarm mode. [1][2] Sources: - Compose Specification — container_name pattern and scaling note. [1] - Docker Compose docs — container_name uniqueness / swarm behavior. [2] --- 🌐 Web query: `Docker Compose service "name" field invalid spec` 💡 Result: That error happens because the top-level "name" key is part of the newer Compose Specification (project name), and older/older-style parsers (classic docker‑compose / mismatched compose-file versions) reject unknown top-level properties. Fixes: - Run the newer Compose implementation that understands the spec: use the modern command "docker compose" (v2+), or upgrade to a compose implementation that implements the compose-spec. [1][2] - Or remove the top-level name and instead set the project name via COMPOSE_PROJECT_NAME or docker-compose -p <name>. [2] - If you must keep using an older parser, avoid the top-level name (or ensure your compose-file targets the correct spec/version). See related discussion/issue. [3] Sources: Compose Specification (name top-level) and Docker docs; related GitHub/StackOverflow threads. [1][2][3] --- 🌐 Web query: `Docker Compose service level properties fields name vs container_name specification` 💡 Result: Short answer - service name = the key in docker-compose.yml under services; used by Compose as the logical service identifier, for default container names (project_service_index), network aliases, environment variable prefixes, and Compose orchestration. [1][2] - container_name = optional field that sets an explicit container name for that service’s container; it overrides Compose’s generated name but prevents scaling beyond one container, is ignored by swarm/stack deploy, and must be unique. [1][2] Important details - Default container name format = <project>_<service>_<index> (managed by Compose). Use different project names (-p) to run same service names separately. [3] - If you set container_name Compose can’t create multiple replicas (scaling errors) and service discovery via other Compose behaviors still uses the service name on the network. [1][2] - In swarm/stack mode container_name is ignored; Swarm generates names differently. [1][2] Sources - Docker Compose / Compose file reference (container_name, behavior). [1] - Compose Specification (services.container_name). [2] - Practical notes about Compose project/service naming and conflicts. [3] --- 🌐 Web query: `Docker Compose "name:" field service invalid properties allowed` 💡 Result: Short answer: Whether a top-level name: (or name: under networks/services) is allowed depends on which Compose schema/parser you’re using. The Compose specification (and Docker CLI "docker compose" v2 which implements it) accepts a top-level name field; the older docker‑compose (v1 Python tool) and some tools/validators still validate against older schemas and will report "Additional property 'name' is not allowed". Use the Compose v2 CLI (or a compose-spec‑aware parser) or remove/avoid that field for older parsers. [1][2][3] What to do: - If you see "Additional property name is not allowed", run the file with the new CLI: docker compose (space) instead of docker‑compose, or upgrade to a compose-spec compliant tool. [1][3] - For networks: some compose schema versions don’t accept a networks.<name>.name entry; ensure you use a supported file version or the compose-spec. [1][4] Sources: - Docker Compose file reference / services and compose spec. [1] - GitHub issues showing "name" added by docker compose v2 and older tools rejecting it. [2][4] - Stack Overflow explanation about compose-spec vs older docker‑compose tools. [3] --- 🌐 Web query: `Docker Compose service properties allowed fields reference documentation` 💡 Result: See the official Compose file reference (Docker Docs) for the full list of allowed service properties and details, and the Compose Specification for the canonical field definitions: - Docker Compose file reference — Services (allowed service fields, field descriptions and examples). [1] - Compose Specification — Services top-level element (canonical specification of service fields and behavior). [2] If you want, I can list the most common service keys (image, build, ports, volumes, environment, networks, depends_on, deploy, secrets, configs, etc.) with brief descriptions and which Compose/engine versions support them. --- 🏁 Script executed: ```shell #!/bin/bash # Search for Docker Compose specification or file reference documentation online # to find the canonical list of allowed service fields curl -s "https://raw.githubusercontent.com/compose-spec/compose-spec/master/spec.md" | head -200 | grep -A 50 "## Services" ``` Repository: smell-of-curry/gobds Length of output: 46 --- 🌐 Web query: `Docker Compose service "name" property invalid not allowed specification` 💡 Result: You're seeing that error because the Compose file you're using contains a top-level or resource "name" key that your Compose implementation/schema/version doesn't accept. Key points and fixes - The Compose file schema varies by tool/version (docker-compose v1, Docker Compose v2 plugin, docker stack). Some versions add a top-level name or accept resource-level name (networks, volumes); older tools or the swarm stack deploy schema reject that property. [1][2] - Quick fixes: 1. Remove the top-level name property from the generated/handwritten YAML (or remove unexpected resource-level name entries). This resolves validation for tools that disallow it. [2][5] 2. Use COMPOSE_PROJECT_NAME or docker compose --project-name (or docker-compose -p) instead of a top-level name. [1][4] 3. If you need resource names (e.g., networks.name), ensure your compose file version and the Compose binary support it — or upgrade Docker Compose to a recent v2 release that implements the newer schema. Matching the compose CLI to the file format version fixes many such errors. [1][3][7] How to troubleshoot (quick) - Run docker compose version (or docker-compose version) to see which implementation you have. If it's the old python docker-compose, consider upgrading to the Compose V2 plugin. [1] - Validate with docker compose config (or docker-compose -f file config) and remove or adjust the offending name line per the tool's allowed keys. GitHub issues show the same error message when schema/version mismatches occur. [2][5] References - Docker Compose services/file reference (compose file schema and sections). [1] - GitHub issues showing "'name' does not match any of the regexes" and "Additional property name is not allowed" when schema/tool mismatch occurs. [2][5] --- 🌐 Web query: `Compose specification service schema allowed fields list container_name` 💡 Result: Yes — container_name is a valid service field in the Compose specification. Key points: - Type: string (custom container name). [1][2] - Regex: SHOULD follow [a-zA-Z0-9][a-zA-Z0-9_.-]+. [1][2] - Effect: if container_name is set, Compose implementations MUST NOT (and Docker Compose will not) scale that service beyond one container — attempting to scale results in an error. [1][2] Sources: Compose spec and Docker Compose docs. [1] https://compose-spec.github.io/compose-spec/05-services.html [2] https://docs.docker.com/compose/compose-file/05-services/ --- </details> **`name` is not a valid service field in Compose spec.** Use `container_name` to set an explicit container name for the service; alternatively, set a top-level `name:` for the project. Without this change, Compose validation will fail. Note: Setting `container_name` prevents the service from being scaled to multiple containers. <details> <summary>Suggested fix</summary> ```diff services: gobds: - name: gobds-proxy + container_name: gobds-proxy ``` </details>  <details> <summary>📝 Committable suggestion</summary> > ‼️ **IMPORTANT** > Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements. ```suggestion gobds: container_name: gobds-proxy build: ``` </details>  <details> <summary>🤖 Prompt for AI Agents</summary> ``` In `@docker-compose.yaml` around lines 2 - 4, The Compose file uses an invalid service field "name" under the "gobds" service; replace that key with "container_name" if you want to set the container's explicit name (or remove it and set a top-level project name instead). Edit the "gobds" service block (service identifier "gobds") to remove the "name" key and add "container_name: gobds-proxy" when appropriate, noting that using container_name will disable scaling for that service. ``` </details>   ✅ Addressed in commit beeffe9

smell-of-curry commented

2026-01-23 15:17:36 +00:00

(Migrated from github.com)

@cursor review

cursor[bot] (Migrated from github.com) reviewed

2026-01-23 15:23:01 +00:00

cursor[bot] (Migrated from github.com) left a comment

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

Cursor Bugbot has reviewed your changes and found 1 potential issue. Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the [Cursor dashboard](https://www.cursor.com/dashboard?tab=bugbot).

docker-compose.yaml

					
				@ -0,0 +1,13 @@

				services:

Volume mount path doesn't match expected config location

Medium Severity

The volume mount ./config:/app/config creates a directory at /app/config, but the application's ReadConfig() function reads from ./config.toml (which resolves to /app/config.toml given the WORKDIR /app in the Dockerfile). Users placing their config.toml in a ./config/ directory on the host will have it mounted to /app/config/config.toml, not the expected /app/config.toml. The app will create a default config instead of using the user's configuration.

### Volume mount path doesn't match expected config location **Medium Severity**  The volume mount `./config:/app/config` creates a directory at `/app/config`, but the application's `ReadConfig()` function reads from `./config.toml` (which resolves to `/app/config.toml` given the `WORKDIR /app` in the Dockerfile). Users placing their `config.toml` in a `./config/` directory on the host will have it mounted to `/app/config/config.toml`, not the expected `/app/config.toml`. The app will create a default config instead of using the user's configuration.    <a href="https://cursor.com/open?data=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImJ1Z2JvdC12MiJ9.eyJ2ZXJzaW9uIjoxLCJ0eXBlIjoiQlVHQk9UX0ZJWF9JTl9DVVJTT1IiLCJkYXRhIjp7InJlZGlzS2V5IjoiYnVnYm90OmRiYWE4OWJiLTMxMmQtNDMyYS05ZTQwLTMyYjcyZjQxMjllYiIsImVuY3J5cHRpb25LZXkiOiJ2UlhtQzRWMU0zaUhBMm9MemcwbW1zclNXM09mZndkUG5Ydkc2WjdnOEVFIiwiYnJhbmNoIjoibWFpbiJ9LCJpYXQiOjE3NjkxODE3ODEsImV4cCI6MTc3MTc3Mzc4MX0.zSuEtr4qfjwBgR0rvgJ5tvMccwSKMD2IFhTtyCmeJvc2e-xOY2kjI0ywKAYhU2q9Y2NFgiey8m7DviOxI4wZcxrcamFBPEa73MOM6S9i_G5ne6p5SmQQKhYMQ5vayFdR76qmwdxIF2PhL3PYMaf3EpQfRig-B-SmBSxqK1uoPnvsqsuYCD-Y96VfKIKLxGtC7tNTn5RMk8r7mGeJp7lR6SioDhJx9kyJK3Lzgm-To-BO7bxhaJQogAVXVwgy_tueJC7G3efS0BgDxZaHqfdMmalc8tfobTU-lnAxvi2InjGOl69nhFvlWQWm7rlimX-bwnMFRtdahk1_Zi7iy8acjg" target="_blank" rel="noopener noreferrer"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/fix-in-cursor-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/fix-in-cursor-light.svg"><img alt="Fix in Cursor" src="https://cursor.com/fix-in-cursor.svg"></picture></a> <a href="https://cursor.com/agents?data=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImJ1Z2JvdC12MiJ9.eyJ2ZXJzaW9uIjoxLCJ0eXBlIjoiQlVHQk9UX0ZJWF9JTl9XRUIiLCJkYXRhIjp7InJlZGlzS2V5IjoiYnVnYm90OmRiYWE4OWJiLTMxMmQtNDMyYS05ZTQwLTMyYjcyZjQxMjllYiIsImVuY3J5cHRpb25LZXkiOiJ2UlhtQzRWMU0zaUhBMm9MemcwbW1zclNXM09mZndkUG5Ydkc2WjdnOEVFIiwiYnJhbmNoIjoibWFpbiIsInJlcG9Pd25lciI6InNtZWxsLW9mLWN1cnJ5IiwicmVwb05hbWUiOiJnb2JkcyIsInByTnVtYmVyIjo0NCwiY29tbWl0U2hhIjoiYmVlZmZlOTljZjgyMzkyZDU3MmVhNzEyMjM0Y2RhYWU4MTcyYzBlZCIsInByb3ZpZGVyIjoiZ2l0aHViIn0sImlhdCI6MTc2OTE4MTc4MSwiZXhwIjoxNzcxNzczNzgxfQ.naKF--KBrxGmkHCmH_y6qTef-PDfwMZIu0hoc1cD8TC5zx4Ppiuz0Y_uofmiNgkyRbnjZuA7vO6oES8nW5wWLR56gssc8kKwpcXkryysVPVz9_naf-Zyve6btgfuW3H5FUMlDLJTicj8CZqgDktmLF4PJDKzjWzbMsmRRg03jctNBDe_qDRyClOTRBXc6e2Y7OpLFMoeHBs3hjSzwSBKOrvce_Fc-jzXwITqhWF3U6-QFgPb8F9amYQP2K2kkotx24jF4n14HlrVlZS9EvP7t0OfGwwugt9nRy0DJQwJGjTk4_kl7L_p2DsnKey49gWerO7wKMXnpsV_NdBZBlyRww" target="_blank" rel="noopener noreferrer"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/fix-in-web-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/fix-in-web-light.svg"><img alt="Fix in Web" src="https://cursor.com/fix-in-web.svg"></picture></a>