Roadmap

Daps Project Roadmap

Planned work for the next release. Items here are future work — not yet implemented. Anything completed moves to readme-changelog.md under its version and is deleted from this doc.

See planning-versioning.md for what makes a change MAJOR, MINOR, or PATCH.

---

Planning: v0.3.2

Documentation: Upgrades

Upgrades are confusing, and should be contextualized in one document so the different kinds can be explained.

That is, what do we mean by upgrades, with regards to:

• Daps itself
• Daps dependencies
  • docker
  • caddy
  • toolkit
• Templated projects
  • The templates themselves, e.g. scripts, compose files
  • Wordpress
    • core
    • plugins
  • Grist
    • ?
  • Astro
    • ?

The details of each can be captured in other documents as it makes sense, e.g. how to upgrade wordpress in the wordpress template doc

version number in dapster

The build script for dapster.org should look for the latest version from the csproj, tags, or changelog somehow

---

Planning: v0.4.0

Upgrade templated projects

We need something like:

dapsman init --update --project <name>

Which would essentially rerun init and overwrite transformed and untransformed files, but not others, depending on the template. Like for wordpress, it would update _scripts and _docker, including the dockerfile. Any user mods to those files would be lost, unless they’re managing things in git and can catch their own mods in the diffs

---

Daps Aspirational Roadmap

Ideas for what to do later, someday. Items can move from here to a specific release plan above.

---

Robustness

prod offline misses single-line and wrapped Caddy site blocks

ReadSiteAddresses (RemoteOfflineStatusPlanBuilder.cs, line 89) recognizes a site block only when a top-level line ends in { (line 102). Two valid Caddy forms slip past it:

• a single-line block — example.com { respond "hi" }
• an address list wrapped across lines, with the { on a later line

A missed block is not a visible error. Its domains are simply absent from the generated offline config and fall through to Caddy’s default handling while the project is meant to be offline. If every block is missed the method throws, which is at least loud; the partial case is the dangerous one.

All four shipped templates use the multi-line form, so this does not bite today — it bites the first user who hand-edits a .prod.caddy into a form Caddy accepts and Daps does not.

The work: parse on brace position rather than line ending — accumulate text until the first top-level {, treat everything before it as the address list, then track depth as now. Extend RemoteOfflineStatusPlanBuilderTests with a single-line block and a wrapped address list.

Note that a user who needs an exact offline config already has an escape hatch: a _caddy_sites/<name>.offline.caddy file is used verbatim when present, and none of this parsing runs.

PATCH.

---

Optimization

Toolkit Linux version (questions, not planning)

Q: The toolkit is ubuntu because that’s what I thought to use, because it’s common, but it appears to be 500MB on disk. Would another distro have made more sense?

A: Reasonable choice, but yes there are lighter options. The short answer: Ubuntu is fine here, the size doesn’t matter much for a toolkit, but here’s the tradeoff landscape:

Why Ubuntu is heavier: It ships with a lot of userspace tooling you don’t need (systemd, snapd stubs, locale data, etc.). The OpenStack CLI is also Python-based and pulls in a significant dependency tree on top of that.

Lighter alternatives:

• debian:bookworm-slim — similar compatibility to Ubuntu, maybe 30-40% smaller. Near-zero migration effort since it’s the same package ecosystem (apt). Probably the most sensible swap if you ever wanted to.
• Alpine — the extreme version (~7 MB base). Alpine uses musl libc instead of glibc, which causes subtle breakage with some Python packages (OpenStack CLI in particular can be finicky). Doable but requires more Dockerfile work and occasional debugging when a package behaves differently.
• python:3.12-slim — since OpenStack CLI is a Python package, starting from a Python image makes the dependency story cleaner. Still Debian-based so full compatibility.

Why it doesn’t matter much here: The toolkit runs continuously on your local machine, is never uploaded to a remote host, and is pulled once then cached. 500 MB sitting idle on disk costs nothing in practice. Size optimization matters most for images that get pulled frequently (CI runners, prod containers scaled horizontally) — neither of which applies to the toolkit.

If you ever revisit it, debian:bookworm-slim would be the lowest-risk swap. Alpine is only worth it if you’re really constrained on disk and willing to do the musl compatibility testing.