Hostityourself/docs/roadmap.md

HIY Roadmap

Goal

A complete self-hosted PaaS that runs on any Linux hardware with zero external service dependencies. You own the git server, the build pipeline, the runtime, the reverse proxy, and the auth — all in one binary + Caddy.

git push hiy main   # deploy your app, nothing else needed

---

Current state

Feature	Status
Web dashboard	✓ done
App CRUD + env vars	✓ done
GitHub webhook deploys	✓ done
Cloud Native Buildpacks + Dockerfile	✓ done
Caddy reverse proxy + auto-HTTPS	✓ done
Multi-user auth with per-app grants	✓ done
Docker-based container runtime	✓ done

---

Planned changes

1. Replace Docker with Podman

Why: Docker requires a daemon running at all times. On low-powered or older hardware this is wasteful. Podman is daemonless, rootless by default, and is a drop-in OCI-compatible replacement. It runs on any Linux (x86, ARM, RISC-V, old laptops, VMs) without root.

What changes:

• build.sh: docker → podman (one-line change per invocation)
• docker-compose.yml: switch the server image to use Podman socket if needed
• No API or model changes — OCI images are the same standard

What stays the same: Cloud Native Buildpacks, image tagging, container networking, resource limits — all work identically with Podman.

---

2. Git push deploy (git push hiy main)

Why: The current webhook flow requires GitHub (or another hosted git service). The goal is zero SaaS dependency. The git-push model is self-contained: SSH is already on every Linux box, and HIY already has everything else needed.

How it works:

developer laptop                   HIY server
────────────────                   ──────────
git push hiy main
  └─ SSH → hiy@myserver            accepts connection (authorized_keys)
       └─ git-receive-pack         receives git objects into bare repo
            └─ post-receive hook   queues a build in HIY's existing build worker
                 └─ build + deploy (same pipeline as today)

Setup (once per app):

git remote add hiy ssh://hiy@myserver/myapp
git push hiy main

What HIY adds:

• Stores a bare git repo per app under HIY_DATA_DIR/repos/<app-id>.git
• An SSH authorized_keys entry per user with a command= override that routes pushes to the right app (same trick Piku and old Heroku use)
• A post-receive hook that calls into the existing build queue
• The app's git URL becomes the repo itself — no external remote needed

Compatibility: The existing GitHub webhook flow keeps working. Both paths feed the same build queue. Users who want to keep using GitHub/Gitea/Forgejo can; users who want full self-containment use git push.

---

3. HIY as its own git server (optional, follows from #2)

Once git push works, HIY can optionally act as the authoritative remote — no Gitea, no Forgejo, nothing external. Developers push to HIY, HIY stores the repo and deploys.

For teams who want a browsable git UI, HIY can integrate with or recommend Forgejo (a fully self-hosted Gitea fork) as a companion — but it is never a requirement.

---

What this looks like when done

Concern	Solution	External service?
Git hosting	HIY bare repos (or self-hosted Forgejo)	No
Deploy trigger	git push hiy main	No
Build	Cloud Native Buildpacks / Dockerfile	No
Container runtime	Podman (rootless, daemonless)	No
Reverse proxy + TLS	Caddy (Let's Encrypt)	No*
Auth	Multi-user, per-app grants	No
DNS	User's own domain / router	No

* Let's Encrypt requires outbound HTTPS on port 443 for certificate issuance. For fully air-gapped setups, Caddy can use a self-signed or manually provided cert.

---

Non-goals

• Not a Kubernetes replacement. HIY targets single-node home/office servers, not clusters. If you need multi-node, use k3s or Nomad.
• Not a managed service. There is no HIY cloud. The point is that you run it.
• Not opinionated about language. Any app with a Dockerfile or a standard buildpack language (Node, Python, Go, Ruby, Java...) deploys without configuration.