More room for a service
Adjust CPU and memory for the workload that needs them.
One app today.
Room for what comes
next.
Deploy your code, connect the services around it, and scale each workload as it grows. Keep releases, logs and resource settings together in one dashboard.
Create your Cloud account Cloud beta. Signup is open; compute availability varies by workspace.
01 / APPLICATION MODELONE SYSTEM. CONNECTED SERVICES.
ONE COHERENT APPLICATION
From a single service
From a single service
to a connected system.
Start with a web app. Add a private API, a worker and a database when you need them. Set CPU, memory and replicas per service. Your app can grow without giving every part the same resources.
Deploy your first application↗ ORIGINAL CONCEPT ILLUSTRATION
02 / A CONNECTED WORKFLOWGIT. CONFIGURATION. SERVICES.
YOUR WORKFLOW, CONNECTED
Start where your code lives.
Connect GitHub or GitLab. Choose a build preset or bring a container image. Keep the deployment definition beside your code.
Connect a sourceCONCEPT DIAGRAM / NOT A LIVE DASHBOARD
your-repositorymain / hakopod.toml
Build presetDockerfileOCI image
Review deployment plan
03 / EVERYTHING HAS ITS PLACEEXPLORE THE DETAILS
01 / Agents
Let your agent see the application.
Connect an MCP client to inspect services, runtime state and logs. Prepare a plan and enable deployment when the task needs it.
Read the guide↗ 02 / DeploymentsShip changes with context.
Immutable application revisions, planned changes, and deployment history keep the next step in context. Roll back a successful configuration without pretending to roll back data.
Read the guide↗ 03 / NetworkingKeep internal services private.
Named service networks, private ports, and scoped virtual networks connect the right services. Explicit grants keep cross-application communication deliberate.
Read the guide↗ 04 / ConfigurationOne file, many ways to work.
Edit TOML in the dashboard or keep it in a repository. Service variables, secret references, resources, and storage use the same canonical configuration.
Read the guide↗ 05 / OperationsFollow the problem to its source.
Inspect services and pods, filter logs, view resource usage, and review alarm events. Diagnose the current workload, not only the last deployment result.
Read the guide↗ 06 / StorageGive your data a recovery path.
Persistent mounts and filesystem permissions give your data a home. Configure object storage for supported backup and restore workflows.
Read the guide↗ 07 / AccessThe right tools, in the right hands.
Start with an installation administrator. Use scoped API credentials, Free team invitations and fixed project roles.
Read the guide↗ WHEN YOUR APP GETS BUSIER
Scale the part
Scale the part
that needs it.
A busy API, a growing queue, another service. Give each workload room to grow from the same dashboard.
Explore resource settings Managed databases / Self-hosted alpha.56
Managed databases.
Managed databases.
Choose your engine.
Choose PostgreSQL, Redis, MySQL, MongoDB or ClickHouse, with private connections and a separate copy for recovery. Inspect the restored data before changing your application’s connection.
Explore managed databases Self-hosted alpha.56 adds Managed MyDuck and Oracle Database Free. Cloud alpha.35 packages the same support. The current shared Cloud service cannot provision Oracle Free or Vitess; MyDuck availability remains capacity-dependent. PostgreSQL + Redis / Recovery workflow
- 01Restore.A separate copy.
- 02Inspect.Your chance to check.
- 03Switch.Only when you decide.
Source data stays available. New writes need a fresh capture before cutover.
NEW AT THE WORKBENCHSELF-HOSTED DEVELOPMENT RELEASES
More of the work.
Within reach.
From the first HTTP request to the server underneath it. A few recent additions to help you run what you build.
Follow a request past the front door.
Find a failed HTTP request, inspect its timings and backend, then check the service’s current route. Query strings, headers and bodies stay out of the log.
Explore RequestsLet the quiet services rest.
Run a JavaScript or Python HTTP function, or bring your own container. Sleep at zero replicas and wake on a request, with an always-warm option when waiting won’t do.
How sleep and wake workPut a service where it belongs.
Choose an exact node for a service, or leave placement automatic. Plans check capacity and storage constraints. A pinned service waits for its node if it goes away.
Choose a node deliberatelyClose the tab. Keep the context.
Send release results to email, Slack, Discord or a signed webhook. Choose the events that matter to each application and inspect delivery history when a message is missing.
Set up notificationsAvailable in the self-hosted alpha releases shown above. Get alpha.21 from GitHub for all of these features. Serverless HTTP runs zero or one replica and needs a configured activation gateway; existing installations must enable it explicitly. Hakopod Cloud remains in development. Illustrations explain the concepts.
04 / SOURCE AND RELEASEKEEP THE EVIDENCE IN VIEW
A commit behind
every build claim.
Build images in your own CI and attach the exact digest, source commit and run URL to the release. Keep the origin of each service visible without guessing from a moving tag.
Connect CI to the releaseCI provenance records what your authenticated pipeline reports. It is not a signed supply-chain attestation or proof that every running pod has updated.
Use the view
that fits the work.
The dashboard, CLI, and REST API share the same application model. No secret second configuration to keep in sync.
See the details.
Projects, applications, deployments, and infrastructure in an interface made for everyday operations.
Keep your flow.
Plan and deploy from your terminal. Use scoped credentials for automation and CI.
Or declare it with TerraformMake it repeatable.
Keep service definitions in version control and review configuration changes with your team.