118 lines
4.2 KiB
Markdown
118 lines
4.2 KiB
Markdown
# 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):
|
|
```bash
|
|
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](https://forgejo.org) (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.
|