Skip to content
dockmesh

Roadmap

A rough plan for where dockmesh is going. Not a commitment — priorities shift. Track actual in-progress work on GitHub Projects.

Now (next 1-3 months)

Section titled “Now (next 1-3 months)”

Focused on polish and stability before a stable v1.0.0:

  • ✅ Core feature set (done in beta releases)
  • 🚧 Test coverage push — bringing Go + frontend to 80%+ coverage
  • 🚧 Performance benchmarking — documented scale limits for SQLite / PostgreSQL
  • 🚧 i18n scaffolding — preparing UI for translations
  • 🚧 Official binaries for linux/arm/v7 (currently manual builds)
  • 🚧 Improved installer — offline/air-gapped install bundle

Next (3-9 months)

Section titled “Next (3-9 months)”

Community and ecosystem:

  • Plugin system — shell-out integrations for custom alert channels, backup targets, webhooks
  • Template marketplace — community-contributed stack templates browsable in-UI
  • Improved Docs — video walkthroughs for each Deploy Tutorial
  • Terraform provider — manage hosts, stacks, env vars declaratively from Terraform
  • Kubernetes read-only support — view K8s clusters alongside Docker hosts (no management, just observability)
  • Mobile-first PWA — better experience on phones (currently responsive but not PWA)
  • Per-user API tokens — currently org-level; per-user tokens for personal automation

Later (9-18 months)

Section titled “Later (9-18 months)”

Speculative — depends on community feedback and capacity:

  • Multi-server HA — currently single-server; HA mode with leader election
  • Compose Extensions — x-dockmesh.* labels for advanced routing/scheduling
  • Improved secret management — native Vault/SOPS integration
  • Built-in reverse tunneling — expose local-only agents to the public internet via dockmesh server (alternative to Cloudflare Tunnel)
  • Application marketplace — curated one-click deploys for popular self-host apps
  • docker run command parser v2 — smarter conversion handling complex cases

Ideas (no commitment)

Section titled “Ideas (no commitment)”

Things we’ve thought about but aren’t planned:

  • Full Kubernetes management — unlikely; K8s is a different tool with different UX. Rancher/Lens do this well
  • Container image builds from source — out of scope; use CI
  • Log aggregation backend — prefer integrating with Loki/Elasticsearch
  • SaaS hosted dockmesh — unlikely; goes against the self-host ethos

How priorities are set

Section titled “How priorities are set”

Roughly, in order:

  1. Security issues — always top priority
  2. Bugs affecting users today — reported via Issues, reproducible
  3. Polish on existing features — gap-filling, UX improvements
  4. Features users have asked for — weighted by Issue reactions + Discussion votes
  5. Features maintainers find interesting — sometimes technical curiosity leads

There’s no paid “move my feature up the list” option — this isn’t a commercial product.

Making features happen faster

Section titled “Making features happen faster”

If you want something specific:

  • Upvote the relevant GitHub Issue (👍 reactions are tracked)
  • Comment with your use case — concrete stories help prioritize
  • Contribute — a well-designed PR beats a wishlist every time
  • Sponsor — financial support via GitHub Sponsors frees up maintainer time

Breaking changes policy

Section titled “Breaking changes policy”

dockmesh follows semver:

  • Patch releases (1.0.x) — bug fixes, no breaking changes
  • Minor releases (1.x.0) — new features, deprecations announced, no breaking changes
  • Major releases (2.0.0, etc.) — breaking changes allowed, migration guide provided

Deprecations are announced at least one minor version before removal. Example:

  • v1.3.0 — API endpoint /foo is deprecated, use /foo-v2
  • v1.4.0 — /foo still works, warns in logs
  • v2.0.0 — /foo removed

Release cadence

Section titled “Release cadence”
  • Patch: whenever bugs need fixing (sometimes weekly)
  • Minor: roughly monthly
  • Major: when accumulated deprecations warrant it (yearly-ish)

See Release Process for details.

Things we’ve said no to

Section titled “Things we’ve said no to”

For context — past requests that won’t be built:

RequestWhy not
Built-in CI/CD (GitHub Actions clone)Use GitHub Actions, Gitea Actions, Drone — they do this better
Built-in log searchUse Loki + Grafana, they’re purpose-built
Desktop appThe web UI IS the app — no maintenance burden of Electron
SaaS offeringConflicts with the self-host ethos
Cloud-provider-specific integrations (AWS LB, etc.)Out of scope; use the provider’s native tools or Terraform

See also

Section titled “See also”