A repository link tells someone you wrote code. A live URL lets them click it. Hostlet Cloud closes that gap: point it at a GitHub project, and it builds, deploys, and keeps a real running app at a *.hostlet.cloud URL — plus a showcase page you can send with an application or a client proposal.
This is a walkthrough for developers evaluating the product. We'll go through the three steps — Connect a repo → Launch the demo → Share proof — and cover how app auto-detection works, when to reach for custom build/start overrides, how continuous deploy behaves on git push, and what URLs you end up with. We'll use a Next.js dashboard as the running example, with notes for an Astro site along the way.
1. Connect a repo
Start at hostlet.cloud and choose Start with GitHub. Authorize access to the repositories you want to deploy, then pick one. For this walkthrough we'll use a Next.js admin dashboard — the same shape as the Modernize Dashboard app in the demo portfolio.
When you select a project, Hostlet inspects the repository to figure out the app shape: what runtime it needs, how to build it, and how to start it. You don't fill out a build matrix by hand — detection is the default, and you only override when you have a reason to.
How auto-detection works
Detection runs in a fixed order, and the first match wins:
- Generated runtime first. Hostlet Cloud keeps self-service projects on generated runtimes so deploys stay predictable, isolated, and cost-controlled.
- Manifest detection. Railpack generates build support from the manifests already in your repo.
What gets detected
Railpack-backed detection covers the common project shapes:
- Node — a
package.json(our Next.js dashboard lands here; an Astro site does too) - Python
- Go
- Rust
- Static sites — plain HTML/CSS/JS output
- Modern manifests — current framework and toolchain manifest files
For the Next.js dashboard, detection reads package.json, recognizes the Node app, and wires up the standard build and start path. For an Astro site, the same package.json-driven flow applies; Astro's build produces output that gets served at your live URL.
2. Launch the demo
With the app shape detected, choose Launch the demo. Hostlet builds the project, deploys it, and keeps it reachable. When the build finishes, you get a running URL on the *.hostlet.cloud domain — a real app you can open, click through, and hand to someone else.
Every app gets its own URL
Your live demo is a deployed app, not a screenshot or a recording. For the dashboard, that means the actual Next.js app responds at its URL — routes, interactivity, and all. This is the "Real apps. Really deployed." part: the link you share is the software running.
When to use custom build/start overrides
Auto-detection handles most repos, but you can override the build and start commands when your project needs something specific. Reach for overrides when:
- Your build command isn't the framework default — for example, a monorepo where the deployable app lives in a subdirectory, or a build that runs a custom script before the framework build.
- Your start command differs from what detection assumes — a non-standard entrypoint, or a server that needs particular flags to bind correctly.
If detection already produces the right build and start steps — which it does for a standard Next.js or Astro project — leave the overrides empty and let detection drive. Override only the piece that's actually different; you don't have to restate the whole pipeline.
A note on what "live demo" means for billing
Here's the honest framing, because it shapes how you'll use Hostlet. The live demo — the always-on running URL — is the metered resource. Your portfolio and showcase pages are free for everyone, on every plan. So you pay only for the apps you keep running live, and you can showcase as many projects as you want regardless.
That maps cleanly onto real situations, and the plans are priced around how many live demos you're keeping up at once:
- Student — $4/mo, 1 live demo. A single course project or hackathon build kept reachable.
- Starter — $9/mo, 2 live demos. A round of internship applications with two apps live at the same time.
- Pro — $19/mo, 4 live demos. Portfolio season, with several projects running across it.
Pick the number of live demos you actually need; the showcase layer around them costs nothing. Full breakdown on the pricing page.
3. Share proof
Once the demo is live, Hostlet generates a showcase page for the project: the live demo, the source context, the detected stack, and a summary, enriched with metadata pulled from GitHub. This is the artifact you send — not a repo link a reviewer has to clone and run, but a page they open with the app already running.
The links you get
- Per-project showcase —
https://[user].hostlet.cloud/p/[project]. One page with the live demo embedded, the stack, screenshots, and source context. This is what goes in an application or a message to a client. - Portfolio page —
https://[user].hostlet.cloud. Your auto-generated public profile, collecting your projects in one place. One link for "here's my work."
You can edit your profile, and the portfolio is built for sharing — there's a mobile share-sheet, so sending your link from a phone is one tap. The demo portfolio at hostlet.cloud/demo shows the finished shape across three deployed apps (Modernize/Next.js, AstroWind/Astro, Vue RealWorld/Vue), and each has a per-project page at hostlet.cloud/demo/p/[project] you can inspect before you build your own.
Continuous deploy on git push
Your demo isn't a one-time snapshot. After the first launch, Hostlet redeploys on every git push to the connected repository. Merge a fix to your dashboard, and the live URL updates with it — no second trip through the launch flow. The URL stays stable while the app behind it tracks your repo. That's what keeps a hackathon demo reachable long after the weekend, and what keeps a client-facing build current with your latest commit.
Troubleshooting: when the build doesn't come up
If a launch doesn't produce a working URL, the usual cause is a mismatch between how your app builds or starts locally and what detection assumed:
- Build fails on a non-default pipeline — set a custom build override that matches the command you run locally (including any subdirectory or pre-build step).
- App builds but the URL doesn't respond — the start command or the bind is likely off. Set a custom start override using the entrypoint and flags your server actually needs.
- An unusual stack detection doesn't cover — set custom build and start overrides so the generated runtime uses the commands your app already needs.
Start from the override that targets the failing step; you rarely need to change more than one.
Ship the proof
The shortest path from "I built this" to "click this and try it" is three steps: connect the repo, launch the demo, share the page. Detection handles the common shapes, overrides handle the rest, and git push keeps it all current.