"The Problem"
Modern development has quietly normalized something risky:
Deployments we don’t fully understand.
You push code to GitHub and suddenly it’s live. No friction. No questions. Just poof.
Platforms like Vercel and Netlify have perfected this experience. The speed feels incredible. The simplicity feels empowering.
Until it doesn’t.
As applications grow more complex, that same “magic” starts to fracture. Builds fail without clear reasons. Deployments behave unpredictably. Logs feel incomplete. Configuration lives somewhere just out of reach.
Developers end up:
Digging through proprietary logs
Guessing build environments
Fighting hidden configuration
The Solution: Hostack
We’re building Hostack to fix that.
Hostack is a "deploy-from-GitHub" platform that gives you the same "Push-to-Deploy" flow you love, but with the engine hood wide open.
The Core Flow: Simplicity Meets Visibility
The Hostack lifecycle is intentionally straightforward:
Repo Hook
A GitHub Action or webhook triggers on push.
Smart Detection
We scan your codebase to identify the framework (Next.js, Astro, Remix, etc.).
Job Queuing
A specialized worker is assigned to your build.
The "Transparent" Build
We build your app in an ephemeral, isolated environment.
Global Deployment
Your artifact is shipped to the edge or a container runtime.
The "How" Matters: Solving the Pain Points
While the flow is simple, the implementation is where it gets interesting.
- Framework Detection: The "Hybrid" Approach One of the biggest debates in building Hostack was how "smart" the platform should be. If we’re too magic (pure heuristics), we’re just another black box. If we’re too manual (explicit config), the DX suffers. We chose the hybrid approach. By default, Hostack scans your package.json and config files to guess the best build command. But every project can include a hostack.yaml. This file acts as your source of truth, allowing you to override any detected settings. Transparency means never having to wonder why a certain build command was chosen.
- Worker Architecture: Clean-Room Isolation In a monorepo, dependencies can become a nightmare. How do you ensure the build for your React frontend doesn’t conflict with your Go-based API or your n8n automations? Hostack uses ephemeral Docker workers. Instead of one massive worker with every runtime installed, our orchestrator pulls a specific "builder image" based on your project type. React? We spin up a node:20-alpine builder. n8n? We spin up a specialized builder with the n8n-cli pre-installed. This ensures your build environment is: Clean Reproducible Auditable You can see exactly which image was used and even run it locally for debugging.
- n8n as a First-Class Citizen We believe automation should be treated like code. That’s why Hostack isn’t just for web apps. By integrating the ubie-oss/n8n-cli, Hostack allows you to manage your n8n workflows directly from your GitHub repo. Using the --git-diff and --externalize flags: Only changed workflows are deployed Complex JavaScript nodes are extracted into separate files Automation is no longer a side tool. It becomes part of your deployment pipeline. Where We’re Going Hostack isn’t just about deploying code. It’s about giving developers the keys to their own infrastructure. We’re exploring even more transparency-focused features: Raw Build Logs Real-time, unfiltered output from the worker Dockerfile Export Automatically generate the exact Dockerfile used for your build PR-Specific Workflow Diffs See exactly what changed in your automation before merging Join the Discussion We’re building this in the open and we want your input. https://github.com/bry92/Hostack-Deploy/discussions/1#discussion-9699264�
Top comments (0)