Inhank Cloud DocsCloud Docs

Resource usage

How Inhank Cloud allocates CPU and memory, and how to scale your service.

Every service runs with a defined amount of CPU and memory, set by its plan. This page explains how those limits work, what happens when you hit them, and how to scale up when you need more.

CPU and memory limits

Each service is given a fixed CPU and memory budget based on its plan:

PlanCPUMemoryBest for
Hobby1 vCPU1 GiBSide projects, demos, low-traffic services
Starter2 vCPU2 GiBMost production services

You pick a plan when you create the service, and can change it any time from Settings → Plan.

What "limit" actually means

  • CPU is a soft cap. If the platform has spare capacity, your service can briefly burst above its limit. Sustained usage at the limit results in throttling — your code runs slower, but it doesn't crash.
  • Memory is a hard cap. If your service exceeds it, your service is restarted automatically (out-of-memory). Traffic continues to be served by other instances if you have multiple.

Seeing live usage

Open your service → Resource Usage tab to see:

  • Current CPU and memory usage per instance, sampled every few seconds.
  • 24-hour history with peaks called out.
  • A forecast of period billing based on actual consumption.

The Project info tab also shows a quick at-a-glance "X of Y CPU / X of Y memory" summary.

What happens when you hit a limit

Memory exceeded (OOM)

Inhank Cloud immediately stops the affected instance and starts a fresh one. The replacement comes up within a few seconds; if you have multiple instances, the others keep serving traffic during the swap.

You'll see this in your logs:

[platform] instance terminated: out of memory
[platform] starting replacement instance

If memory exhaustion is recurring, options are:

  • Fix the leak. Profile your app locally to find what's growing unbounded.
  • Reduce memory pressure. Lower per-process worker counts, batch sizes, cache sizes.
  • Scale up the plan. Move from Hobby → Starter → Pro.

CPU exhausted

Your service keeps running, but each request takes longer because the CPU budget is saturated. Symptoms:

  • Increased response latency
  • Higher tail latencies (p95, p99)
  • Background jobs taking longer to complete

Options:

  • Profile and optimize hot paths. A flame graph from a tool like clinic.js (Node), py-spy (Python), or pprof (Go) usually shows the culprit.
  • Add a worker pool / async for heavy work, so the main thread stays free for requests.
  • Scale up the plan.
  • Scale horizontally by running more instances (see below).

Inhank Cloud immediately spins up additional instances (or terminates extras) without interrupting traffic.

Automatic restarts

Even within limits, instances can be restarted by the platform when:

  • The application crashes (uncaught exception, segfault, exit 1).
  • The instance exceeds its memory limit.
  • The instance fails its health check repeatedly.
  • The underlying host needs maintenance.

In every case, Inhank Cloud automatically starts a replacement. You'll see the restart in the Logs tab and in Resource Usage as a brief drop in active instances.

For graceful restarts, your application should:

  • Handle SIGTERM and finish in-flight requests before exiting (most web frameworks do this automatically).
  • Avoid holding state across requests in process memory.

Plan changes

To change your plan:

  1. Open your service.
  2. Go to Settings → Plan.
  3. Pick the new plan.
  4. Confirm.

The change takes effect on the next release of your service. To apply it immediately, click Redeploy after changing.

Billing is prorated at the period boundary — see Billing: plans and renewal.

Bandwidth and outbound traffic

Each plan includes a generous monthly bandwidth allowance. Most services never hit this limit. If you're shipping large files or media (video, images) at scale, contact us before launch.

PlanBandwidth Limit
Hobby10 GB
Starter25 GB

Best practices

  • Right-size your plan. Start on Hobby for a side project, move up when you see sustained CPU > 70% or recurring memory pressure in Resource Usage.
  • Profile before upgrading. A 2x bigger plan is fine, but optimizing one slow query is usually cheaper and faster.
  • Watch for memory creep. Long-running Node and Python processes can slowly grow over days. If you see this, a daily scheduled restart can be a temporary mitigation while you fix the leak.
Adjust scaling and plan
Pick the right plan and instance count for your service.

On this page