Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(infra): run Kubo in docker-compose (server profile, pinned version)

Closed
  • Is something wrong?
#59 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@SaishKorgaonkar is already working on this.

Since Oct 22, 2026.

  • #80 by @SaishKorgaonkar — merged

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
docker, docker-compose
Domain
devops, infrastructure

Research direction

Start with docker-compose.yaml and the current backend and Caddy services; check the pinned Kubo release documentation before choosing the image tag and config keys. Add the service, healthcheck, and network and port settings, then document the version and settings in the README. Write a smoke script under scripts/ that adds and cats content and checks matching CIDs; done means the service becomes healthy and the RPC port stays private.

Written by the indexing model from the issue text.

Description

enhancement kubo storage tier-2

Summary

Add an always-on Kubo node to the compose stack as the platform's content node.

Estimated size: M

Motivation

Browser Helia nodes come and go; an always-on peer is what lets a shared CID open on another machine.

Current state in this repo

  • docker-compose.yaml runs backend and caddy; there is no IPFS node.

Proposal

  • Add a kubo service with a pinned image tag (not latest), a persistent volume and the server config profile applied at init.
  • Publish swarm (4001 tcp/udp) as needed; keep the RPC API (5001) on the compose network only; publish the gateway (8080) to localhost in dev.
  • Add a healthcheck and a README section recording the Kubo version and the config keys used, with a link to the docs for that version (verify every setting against the release you pin).

Acceptance criteria

  • docker compose up kubo becomes healthy.
  • A script performs add then cat through the node and prints matching CIDs.
  • The RPC port is unreachable from outside the compose network.
  • No secrets are committed.

Out of scope

  • Production hosting; browser transports; auth (separate issues).

Dependencies

  • None; can be picked up independently.

Testing plan

  • Smoke script in scripts/; later wired into CI by the integration-test issue.

Part of #43. Ground rules for the content layer: no secrets in the repo, content-layer failures must never block or discard quantum execution, and tests and docs ship with every PR.

Dominant language
Python
Stars
2
Forks
4
Avg merge
5h 19m
Merged PRs (30d)
11

Getting set up

  • Ships a Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from QMeshPy/distributed-quantum

All issues in QMeshPy/distributed-quantum

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.