Documentation

Hubfly space documentation

Deploy containers, multi-service stacks, background workers and GPU workloads from GitHub, a Docker image or a template without running the infrastructure underneath.

The four documentation hubs

The documentation is split into four hubs. Each one has its own navigation, so you only see the pages that belong to what you are working on. Switch between them using the tabs at the top of every page.

Platform documentation

Deploy, network, scale and operate workloads.

SDK documentation

Typed TypeScript and Go clients for the platform API.

API documentation

The REST API behind every dashboard, SDK and CLI action.

CLI documentation

Drive the whole platform from a terminal or a CI job.

Pick a starting point

These are the ways to get a service running. Start with the quick start if you are evaluating the platform, or go straight to the workflow that matches how your service is already built.

Quick startStart here

Create a project and launch your first service in under five minutes.

Deploy from Git

Connect a GitHub or self-hosted repository and build directly from source.

Deploy from an image

Run any Docker image with custom entrypoints, ports and runtime settings.

Templates

Launch curated database, app and stack starters without building from scratch.

Operate what you shipped

Once a service is live, these guides cover the capabilities around it — runtime behaviour, networking, storage, traffic and accelerated compute.

Platform overview

Projects, runtime tiers, resource sizing and platform boundaries.

Compose stacks

Deploy multi-container services with dependency gates and private networking.

Volumes & storage

Attach persistent storage and keep data across restarts and redeploys.

Networking

Internal aliases, public HTTP/TCP endpoints and custom domains.

Load balancers

Distribute traffic across container targets with routing policies.

Firewall

Rate limiting, bot protection and IP access policies for public domains.

HubTunnels

Reach internal services privately without exposing a public endpoint.

Scaling

Vertical and horizontal scaling, auto-sleep and resource limits.

GPU deployments

Provision accelerated workloads, Jupyter notebooks and GPU compute.

Container runtime tiers

Every container runs on one of two tiers. The tier decides how the container is scheduled and whether it is allowed to sleep while idle.

Tier	Default sizing	Runtime behaviour	Best for
`shared`	0.3 vCPU · 256 MB RAM · 5 GB storage	Shared compute pool, auto-sleep enabled	Development, staging, internal tools, proofs of concept
`dedicated`	1.0 vCPU · 512 MB RAM · 20 GB storage and up	Always on, optional vertical auto-scaling	Production web apps, APIs, databases, anything with an SLA

A common split

Run shared containers in development and staging and dedicated containers in production. Costs stay predictable without giving up reliability where uptime actually matters.

Getting help

Press ⌘K (or Ctrl K) anywhere in the documentation to search every page across all four hubs. If something is wrong, unclear or missing, emailsupport@hubfly.space or reach the team fromthe contact page. Live incidents and maintenance windows are published on the status page.