Platform

Hubfly Space is a cloud deployment platform for running containerized applications, Compose stacks, persistent storage, private networking, public endpoints, environment configuration, and usage-based infrastructure in one project workspace.

The platform is designed for teams that want the operational model of containers without managing servers, reverse proxies, volume wiring, firewall rules, deployment scripts, and resource accounting by hand. Developers can deploy from templates, Git repositories, Docker images, Docker Compose, or the CLI, then attach storage, configure runtime resources, expose services, and monitor usage from the project dashboard.

Use this page as the operational overview for how Hubfly Space is structured. For implementation-specific guides, see the dedicated docs for deployments, volumes, networking, tunnels, load balancers, templates, Compose, and GPU workloads.

Overview

A Hubfly Space project is the operational unit for an application or application environment. A project can contain one or more containers, Compose services, managed volumes, environment variables, network aliases, public endpoints, custom domains, load balancer groups, tunnels, team members, and budget controls.

The platform is useful when you need to deploy application infrastructure without maintaining a virtual machine fleet. Instead of manually provisioning servers, installing Docker, configuring Caddy or Nginx, managing container restarts, tracking resource usage, and wiring persistent disks, Hubfly Space provides a managed control plane for those workflows.

Hubfly Space is commonly used for:

• Web applications and APIs
• Internal tools and dashboards
• Background workers and queues
• Docker Compose applications
• PostgreSQL, Redis, MinIO, and other stateful services
• Preview environments and staging systems
• Private services exposed through tunnels
• GPU-backed notebooks, AI tools, and model workloads

Core Model

Hubfly Space organizes infrastructure around a few user-facing concepts:

A project should usually represent a meaningful operational boundary, not just a folder. For example, a production SaaS app, a staging environment, a customer-specific deployment, or a data-processing workspace can each be a separate project.

Use Cases

Use Hubfly Space when you want managed container hosting with practical DevOps controls and less infrastructure maintenance.

For application teams, Hubfly Space can replace a manually managed VM where Docker, reverse proxy configuration, persistent storage, SSL, and deployment scripts would otherwise be maintained by the team.

For DevOps and platform teams, Hubfly Space provides a consistent deployment surface for developers while keeping resource sizing, storage, networking, and billing visible.

For startups and small teams, Hubfly Space is useful when you need production-capable deployment workflows without building a full internal platform.

For agencies and consultants, projects provide a clean way to separate client workloads, environments, storage, domains, and costs.

Architecture And Workflow Overview

A typical production workflow looks like this:

1. Create a project in the target region.
2. Choose a deployment source such as Git, Docker image, template, CLI, or Compose.
3. Configure CPU, RAM, storage, runtime behavior, ports, and environment variables.
4. Attach managed volumes for persistent application data.
5. Expose public HTTP or TCP endpoints only where needed.
6. Add custom domains, load balancer rules, or tunnels based on access requirements.
7. Deploy the container or Compose stack.
8. Monitor logs, metrics, billing, storage usage, and health signals.
9. Iterate with redeploys, resource changes, storage growth, and environment updates.

The important production rule is to separate immutable application code from mutable runtime data. Application code should live in an image or repository. Runtime state should live in volumes, databases, object storage, or external managed services.

Requirements

Before deploying production workloads, prepare the following:

• A project with the correct region selected
• A deployment source such as a Git repository, Docker image, template, Compose file, or CLI build
• Any required environment variables, secrets, ports, commands, and health expectations
• Persistent volumes for stateful data
• A clear storage performance mode for each volume
• A networking plan for public and private access
• A backup and restore plan for databases and important files
• A budget or usage review process for paid resources

For Git deployments, make sure the repository contains the expected application entrypoint, build files, and runtime commands. For Docker image deployments, use a tagged image that can be pulled reliably. For Compose deployments, review named volumes, service dependencies, exposed ports, and environment variables before importing.

Supported Environments

Hubfly Space supports single-container and multi-service container workloads. The platform works best with applications that can run as Docker-compatible services and expose predictable ports or background processes.

Good fits include:

• Node.js, Python, Go, Ruby, PHP, Java, and .NET web services
• REST APIs, GraphQL APIs, and backend workers
• Static app servers and reverse-proxy-backed services
• Docker images from registries
• Git repositories with buildable app code
• Docker Compose stacks with named volumes
• Databases and stateful services that can run in containers
• Services that need private networking inside a project

Less ideal fits include workloads that require direct host access, custom kernel modules, non-containerized system services, unmanaged host bind mounts, or storage behavior that depends on a specific machine path.

Deployment Sources

Hubfly Space supports multiple deployment sources so teams can choose the workflow that matches their existing delivery process.

Single-container deployments support:

• Templates for common software and application patterns
• Git deployments for repository-based builds
• Docker image deployments for prebuilt images
• CLI deploys for local-to-platform delivery workflows

Compose deployments support these source types per service:

• Docker images
• Templates
• Git services

Use templates when you want the fastest path to a known service. Use Git when the platform should build from source. Use Docker images when your CI system already builds and publishes images. Use CLI deploys when developers need a direct local workflow. Use Compose when the application is naturally multi-service.

Deployment Source Examples

Use Git for an application API:

Source: Git repository
Workload: Node.js API
Recommended use: app source is built during deployment
Common requirements: build command, start command, runtime environment variables

Use Docker image for a CI/CD pipeline:

Source: Docker image
Workload: production API image
Recommended use: CI builds and tests image before deployment
Common requirements: image tag, exposed port, runtime environment variables

Use Compose for a complete app environment:

services:
  api:
    image: my-org/api:latest
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://postgres:postgres@db:5432/app
  db:
    image: postgres:16
    volumes:
      - postgres-data:/var/lib/postgresql/data
 
volumes:
  postgres-data:

Tiers And Runtime

Hubfly Space supports two main app deployment tiers:

Shared deployments use a locked runtime profile:

• autoSleep: true
• autoScale: false
• is24x7: false

Dedicated deployments can toggle runtime behavior:

• Auto-sleep for workloads that do not need to run continuously
• 24/7 runtime for always-on services
• Auto-scale flag in configuration where supported by the deployment flow

Use shared deployments for small apps, demos, tutorials, and non-critical services. Use dedicated deployments when uptime, performance, resource control, or production reliability matters.

Default Resources

The current deployment tier definitions are:

Compose stacks inherit these same defaults and can override resources per service. Services with larger resource needs should use dedicated sizing.

For production workloads, start with a conservative resource allocation, observe real CPU and memory behavior, then resize based on data. Avoid oversizing every service by default, but do not run databases, queues, or latency-sensitive APIs at the edge of memory limits.

Pricing

Hubfly Space pricing is based on the resources your workloads use. The core app pricing model is built around CPU, RAM, and storage.

Shared deployments include:

• 360 free runtime hours per month
• 5 GB free ephemeral storage

Storage is not the same as runtime compute. Persistent volumes remain allocated until deleted, so plan storage lifecycle as carefully as container lifecycle. Stopping, sleeping, or redeploying a container should not be treated as deleting the persistent data attached to it.

For cost planning, estimate monthly usage from the resources that stay allocated and the runtime pattern of the workload. Always-on APIs, production databases, and large persistent volumes should be reviewed separately instead of bundled into one vague monthly estimate.

Storage

Hubfly Space uses managed volumes for persistent application data. A managed volume is project-scoped storage that can be attached to a container or Compose service and mounted into the filesystem at a path your application expects.

Use managed storage when your workload writes data that must survive container restarts, image redeploys, build rollbacks, or application upgrades. Common examples include PostgreSQL data directories, Redis persistence files, MinIO object data, uploaded media, generated reports, queue state, cache snapshots, search indexes, and application-managed backups.

Storage is separate from ephemeral container disk. Ephemeral storage is useful for temporary files, dependency caches, scratch space, and build-time artifacts, but it should not be treated as durable application state. If the data matters after a redeploy, store it on a managed volume.

Storage Workflow

Single-container deployments can attach existing project volumes during the storage step. You select the volume, choose the mount path, and deploy the container with that storage available inside the runtime filesystem.

Compose stacks can create and attach managed volumes from the Compose definition. Named volumes in Compose YAML are converted into project-managed volumes so stateful services such as databases, object storage servers, and message brokers keep their data across stack updates.

Compose YAML import also supports managed volume creation from the stack definition. This lets teams move Docker Compose workloads into Hubfly Space without manually recreating every named volume in the dashboard first.

Performance Modes

Hubfly Space storage supports three performance modes: Standard, Balanced, and High Performance. These modes help users match the storage profile to the I/O pattern of the application.

Choose Standard when you need reliable persistent storage but your workload is not storage intensive. This is the right default for configuration, basic file uploads, lightweight application state, low-traffic internal tools, and services where CPU or network latency matters more than disk throughput.

Choose Balanced when the workload mainly reads or writes larger files. Balanced is a strong fit for MinIO buckets, media libraries, video or image processing, backup repositories, analytics exports, document storage, large logs, model artifacts, and datasets. It is designed for workloads where sustained transfer behavior matters more than small-file latency.

Choose High Performance when the workload depends on fast small-file access or frequent random I/O. Databases and database-like systems usually belong here: PostgreSQL, MySQL, SQLite-backed services, Redis persistence, search indexes, queue brokers, metadata catalogs, and applications that constantly update many small files. High Performance is the safest option when storage latency can directly affect request latency or transaction throughput.

Storage Requirements

Volumes belong to a project and are created in the same region as that project. Containers and Compose services should mount volumes from their own project and region so storage remains close to the workload and avoids cross-region data movement.

Every volume needs a clear size allocation. Size storage for expected growth, not only current usage. Running a database or object store near full capacity can cause write failures, slow compaction, failed migrations, and application errors that are harder to recover from than a planned resize.

Mount paths should be explicit and application-aware. For example, mount a PostgreSQL volume at the database data directory expected by the image, mount MinIO data at the object storage path, and mount application uploads where the application already writes user-generated files.

Storage Deployment Examples

For a database container, create a High Performance volume and mount it at the database data path. This gives the database persistent storage optimized for small random reads, WAL writes, indexes, and metadata updates.

Workload: PostgreSQL
Storage mode: High Performance
Mount path: /var/lib/postgresql/data
Reason: transaction logs, indexes, and database pages create many small I/O operations

For a MinIO container or S3-compatible object storage service, create a Balanced volume and mount it at the object data path. This favors sustained large-file reads and writes for buckets, backups, media, artifacts, and datasets.

Workload: MinIO
Storage mode: Balanced
Mount path: /data
Reason: object storage usually moves larger files and benefits from throughput optimization

For a simple app that stores occasional user uploads or generated reports, use Standard storage until metrics show the volume is becoming a bottleneck.

Workload: Internal dashboard
Storage mode: Standard
Mount path: /app/uploads
Reason: predictable persistent storage without a higher performance multiplier

Docker And Kubernetes-Style Storage Patterns

In single-container deployments, configure storage by selecting a project volume and assigning the mount path inside the container.

In Compose deployments, define named volumes and mount them into services that need persistent data.

services:
  postgres:
    image: postgres:16
    volumes:
      - postgres-data:/var/lib/postgresql/data
 
volumes:
  postgres-data:

When this stack is deployed, postgres-data should be treated as durable database storage. For production PostgreSQL, use High Performance storage because database workloads generate many short writes and random reads.

If you are coming from Kubernetes, treat Hubfly managed volumes like persistent volumes from an operational point of view: they should be sized deliberately, mounted into the correct container path, protected with backups, and separated by workload when possible.

For a full storage user guide, see Volumes.

Environment Variables

Project environment variables are merged with container variables during deploy. This gives teams a project-level configuration layer and a container-level override layer.

Use project environment variables for values shared across multiple containers in the same project, such as internal service URLs, shared feature flags, environment names, or common integration settings.

Use container environment variables for service-specific configuration, such as a web process port, worker concurrency, database schema name, queue name, or service-specific credentials.

Merge behavior:

• Matching keys are overwritten by the container value
• Git deploys can categorize variables as build, runtime, or both
• Docker and template deploys use runtime environment variables

Environment Variable Best Practices

Keep secrets out of images and repositories. Values such as database passwords, API keys, tokens, and private credentials should be injected as environment variables rather than committed to source control.

Use predictable names. Prefer common names such as DATABASE_URL, REDIS_URL, PORT, NODE_ENV, APP_ENV, and S3_ENDPOINT where the application framework supports them.

Separate build-time and runtime values. A value needed to compile an app is not always safe or necessary at runtime, and a runtime secret should not be exposed to the build process unless the build requires it.

Document required variables in the project README or release checklist so future deployments do not fail because an operator missed a required key.

Networking

Each container receives private project networking and can optionally expose public access. The private network lets containers inside the same project communicate without exposing every service to the internet.

Public access options include:

• Public HTTP endpoints
• Public TCP endpoints
• Attached custom domains
• Load balancer groups
• HubTunnels for private access

Internal aliases are generated from the project, region, and container name unless you override them in supported flows.

Networking Patterns

Use private networking for service-to-service communication. For example, an API container should connect to a database or Redis service over the project network instead of exposing the database publicly.

Use public HTTP endpoints for web apps, APIs, dashboards, webhook receivers, and browser-accessible services.

Use public TCP endpoints only when the protocol needs raw TCP access and the service is safe to expose with the right authentication and firewall posture.

Use custom domains for production user-facing services. Domains make routing stable for users and external integrations.

Use load balancer groups when traffic should be distributed across multiple containers or when you need a stable entry point for a group of related services.

Use HubTunnels when a service should be reachable privately without opening it as a public internet endpoint.

Networking Considerations

Expose the smallest surface area possible. Databases, queues, admin panels, and internal APIs should usually stay private unless there is a specific operational reason to publish them.

Make ports explicit. Container images often expose defaults, but production deployment should intentionally map the service port that receives traffic.

Design health checks around the real service path. A container that starts successfully is not always ready to serve traffic, connect to a database, or process jobs.

For multi-service Compose stacks, verify service names, internal URLs, and dependency order. A service should connect to the correct internal hostname and port, not to localhost unless the dependency runs in the same container.

CI/CD Integration

Hubfly Space can fit into several delivery models.

Use Git deployments when the platform should build and deploy directly from a repository. This is simple for teams that want fewer moving parts and a direct source-to-runtime workflow.

Use Docker image deployments when CI already builds, tests, scans, and publishes images. In this model, Hubfly Space becomes the runtime environment, while your CI system owns image creation and validation.

Use CLI deploys when developers need controlled deployments from a local or scripted workflow.

Use Compose deployments when a release includes multiple services that should be deployed together.

CI/CD Production Workflow

A practical CI/CD workflow is:

1. Run tests and static checks in CI.
2. Build the application image.
3. Push the image with a unique tag.
4. Deploy the tagged image to Hubfly Space.
5. Run smoke checks against the public or private endpoint.
6. Watch logs, metrics, and error rates after release.
7. Keep persistent storage attached across image updates.

Do not treat redeploys as data migration plans. If the release changes database schema or persistent file layout, run an explicit migration step with backup validation.

Monitoring And Logging

Production operations require more than a successful deployment. Monitor the signals that indicate whether the workload is healthy and cost-effective.

Watch these areas:

• Container status and restart behavior
• Application logs and deployment logs
• CPU and memory usage
• Storage allocation and growth rate
• Public endpoint availability
• Project budget usage
• Database and queue errors surfaced in application logs
• Failed builds, failed redeploys, and failed health checks

Logs are most useful when applications write structured, actionable messages. Include request IDs, job IDs, error types, and dependency names where possible. Avoid logging secrets, tokens, full credentials, or sensitive user data.

Security Best Practices

Use least privilege at every layer. Only expose ports that need public traffic, only mount volumes into containers that need them, and only share project access with teammates who need operational control.

Keep secrets in environment variables or a secret-management workflow instead of embedding them in images, Compose files, or Git repositories.

Use private networking for internal dependencies. Databases, Redis, object storage control surfaces, and admin tools should not be public by default.

Use dedicated projects for production when access boundaries matter. Production workloads should not share the same operational space with experiments unless the team intentionally accepts that risk.

Before deleting containers, volumes, or projects, verify whether the resource contains persistent state or production traffic. Volume deletion is especially sensitive because it removes durable application data.

Scaling Considerations

Scaling decisions should be based on the bottleneck of the workload.

Scale CPU when requests are compute-heavy, builds are slow, workers are saturated, or application latency correlates with CPU usage.

Scale RAM when the application is memory-bound, garbage collection is frequent, caches need more headroom, or the service is being restarted due to memory pressure.

Scale storage capacity before a volume reaches full usage. Databases and object stores can fail writes or become unstable when there is not enough free space for logs, indexes, compaction, temporary files, or uploads.

Scale storage performance based on I/O pattern. Use Balanced for large files and High Performance for databases or many short file operations.

Scale architecture when one container is carrying responsibilities that should be separated. For example, split web, worker, database, and cache roles into separate services when their resource patterns differ.

Performance Notes

Performance depends on resource sizing, storage mode, application behavior, network paths, and dependency health.

For web apps and APIs, CPU and memory usually affect request throughput and latency. For databases, storage latency and available memory can be just as important as CPU. For object storage and media workloads, sustained throughput and large-file behavior matter more than tiny random writes.

Use Standard storage for normal reads and writes, Balanced storage for large-file optimization, and High Performance storage for short-file or database-heavy workloads.

Auto-sleep can reduce costs for inactive services, but it is not appropriate for every production workload. Use always-on runtime for services that must receive traffic immediately, process background jobs continuously, or maintain long-lived connections.

Troubleshooting

Deployment Fails

Check the deployment source first. For Git deployments, verify the repository, branch, build command, start command, and required build variables. For Docker image deployments, verify the image name, tag, registry credentials, and exposed port. For Compose deployments, verify YAML syntax, service names, images, environment variables, and named volumes.

Container Starts But The App Is Not Reachable

Confirm the application is listening on the expected port and binding to the correct interface. Many frameworks default to localhost, but containerized services usually need to listen on 0.0.0.0 so traffic can reach the process.

Also verify public endpoint configuration, custom domain routing, and whether the service should be reached through private networking instead of public access.

Service Cannot Connect To Database Or Redis

Check whether the dependency is in the same project network and whether the application is using the correct internal hostname, port, username, password, and database name. Do not use localhost for a dependency running in another container.

Data Disappears After Redeploy

Confirm that the application writes to a managed volume mount path, not only to ephemeral container storage. Also verify that the same named volume or project volume is attached after redeploy.

Storage Performance Is Poor

Check whether the selected storage mode matches the workload. Use Balanced for larger files and High Performance for databases, indexes, queues, and many short random reads or writes.

Costs Are Higher Than Expected

Review CPU, RAM, storage allocation, runtime mode, always-on services, persistent volumes, and GPU workloads. Stopped or sleeping containers and allocated volumes have different cost behavior, so evaluate compute and storage separately.

Common Errors

Best Practices

Design projects around environments and ownership. Production, staging, development, and customer-specific workloads often deserve separate projects.

Keep containers stateless unless they intentionally use a managed volume. Application images should be replaceable without losing runtime data.

Use Compose for tightly related multi-service applications, but avoid hiding unrelated production systems inside one oversized stack.

Use project-level environment variables for shared configuration and container-level variables for service-specific overrides.

Keep internal services private by default. Expose only the public entry points that users or integrations need.

Use clear naming for containers, volumes, endpoints, and domains so operators can understand the system quickly during an incident.

Set budgets or review billing regularly for production projects, especially when storage, always-on services, or GPU workloads are involved.

Production Recommendations

For production APIs, use dedicated runtime, explicit resource sizing, clear health expectations, public endpoints or custom domains, and private networking for dependencies.

For production databases, use managed volumes with High Performance storage, stable mount paths, backups, and controlled migration workflows.

For object storage, media, artifacts, and backups, use Balanced storage and monitor growth rate carefully.

For background workers, separate worker containers from web containers so each can be scaled, restarted, and monitored independently.

For CI/CD, prefer immutable image tags and explicit release steps. Avoid deploying untested floating tags directly to production.

For security, keep secrets out of source control, avoid unnecessary public endpoints, use least-privilege project access, and validate destructive actions before deleting volumes or projects.

Limitations

Hubfly Space is designed for containerized workloads. It is not a replacement for every low-level VM use case, especially workloads that require direct host customization, kernel-level changes, or machine-specific host paths.

Volumes are region-bound operational resources. Cross-region movement requires data migration into a new volume in the target region.

Persistent volumes protect data across container lifecycle changes, but they are not a complete backup strategy. Production systems should still use application-aware backups and tested restore procedures.

Shared runtime is best for lightweight and non-critical workloads. Production workloads that need predictable uptime and resource control should use dedicated sizing.

FAQ

What Is A Project?

A project is the main workspace for containers, volumes, networking, teammates, and cost visibility. It should represent an application, environment, customer deployment, or operational boundary.

Should I Use Shared Or Dedicated Runtime?

Use shared runtime for free-tier apps, experiments, learning, and low-traffic non-critical services. Use dedicated runtime for production systems, always-on services, databases, APIs, workers, and workloads that need predictable performance.

When Should I Use A Managed Volume?

Use a managed volume whenever the application writes data that must survive redeploys, restarts, or image changes. Databases, uploads, object storage, queues, and generated files usually need persistent storage.

Which Storage Mode Should I Choose?

Use Standard for normal reads and writes, Balanced for large files, and High Performance for databases or workloads with many short file operations.

Can Compose Create Volumes?

Yes. Compose stacks can create managed volumes from named volumes in the stack definition. Keep volume names stable across deployments to avoid accidentally creating new empty storage.

Should Internal Services Be Public?

Usually no. Keep databases, queues, caches, and internal APIs on the private project network unless there is a specific reason to expose them publicly.

Does Persistent Storage Replace Backups?

No. Persistent storage keeps data across container lifecycle events, but it does not replace backup, restore testing, retention policies, or application-aware export procedures.

Real-World Examples

Production Web API With Database

Create one project for production. Deploy the API as a dedicated container, attach a public HTTP endpoint or custom domain, keep the database private, and mount the database data directory on a High Performance volume. Store DATABASE_URL, API secrets, and runtime flags as environment variables. Run schema migrations as a controlled release step.

MinIO Object Storage Service

Deploy MinIO from a template or Docker image. Attach a Balanced volume at the object data path because object storage usually handles larger files, backups, artifacts, and media. Keep admin credentials in environment variables, expose only the required endpoint, and monitor volume growth.

Compose-Based Application

Import a Compose stack with an API, worker, Redis, and PostgreSQL. Use named volumes for PostgreSQL and Redis persistence. Keep API public, keep Redis and PostgreSQL private, and use project environment variables for shared settings. Choose High Performance storage for PostgreSQL and Standard or High Performance for Redis depending on persistence intensity.

Internal Tool With Private Access

Deploy the tool as a dedicated or shared container depending on usage. Keep it private by default and expose access through HubTunnels when the service is for internal users only. Use Standard storage for occasional uploads or generated reports unless the workload becomes storage-heavy.

Related Docs

• Volumes
• Networking
• Tunnels
• Load Balancers
• Compose
• Templates
• GPU Deployments