← Back to blog

Gibil v0.3.2: Your Servers, Your Timeframe

Human-friendly TTL durations, a 1-year cap, and no more mental math. Here's what changed and why.

You create a server for a weekend project. You set --ttl 60 because that's the default and you didn't think about it. Two hours in, you're deep in a Docker migration and the server disappears. Your work is gone. You create another one and set --ttl 1440 this time, hoping that's a day. It is, but you had to do arithmetic to figure that out.

We kept hearing this. TTL was the feature that protected you from forgotten servers, but it was also the feature that killed your work at the worst possible moment. The unit was minutes. The cap was 7 days. The mental model was "guess a number and hope."

v0.3.2 fixes this.

Say what you mean

TTL now accepts human-readable durations. No conversion tables needed.

gibil create --name weekend-project --ttl 2d
gibil create --name agent-runner --ttl 1w
gibil create --name long-experiment --ttl 3mo

The full set of units: m (minutes), h (hours), d (days), w (weeks), mo (months), y (years). Plain numbers still work and still mean minutes, so --ttl 60 is unchanged.

The same syntax works everywhere TTL appears — create, extend, branch, and MCP's create_server tool.

# Extend a running server
gibil extend my-app 7d

# Branch with a longer window
gibil branch feat/payments --ttl 2d --run "pnpm test"

The cap is now 1 year

The old 7-day maximum made sense when gibil was a quick-task tool. But real usage patterns don't fit in a week. An agent running a multi-day migration needs more than 7 days. A staging environment for a client demo needs a month. A persistent dev box needs longer still.

The cap is now 525,600 minutes — one year. You probably won't use it, but you can.

gibil create --name staging --ttl 6mo
gibil create --name dev-box --ttl 1y

The server still auto-destroys when the TTL expires. That's the whole point of ephemeral compute — everything has a deadline. But now the deadline can be weeks or months away, not just days.

Extend works the same way

gibil extend accepts the same durations. Need another week on a server you created yesterday? Say so.

gibil extend my-app 7d

When you extend, gibil clears the old shutdown timer and sets a fresh one. The TTL you set is the TTL you get.

Better time display

gibil list used to show remaining time in raw minutes or hours, which got awkward for long-lived servers. Nobody wants to read "4320 minutes remaining."

Now it shows days when appropriate:

NAME            IP              TTL REMAINING    STATUS
staging         91.107.210.27   3 days 5h        running
quick-test      49.13.72.88     22m              running

For agents: MCP gets the same treatment

If you're using gibil's MCP server to let Claude Code or other agents create servers, the create_server and extend_server tools now accept the same human-friendly durations. The MCP cap also moved from 24 hours to 1 year.

An agent can now request exactly what it needs:

{
  "tool": "create_server",
  "input": {
    "name": "migration-runner",
    "repo": "https://github.com/you/project",
    "ttl": "2d"
  }
}

No more agents setting "ttl": 1440 and hoping that's enough.

Type-check cleanup

We also fixed three TypeScript errors that were hiding in the codebase — unused imports in the branch command and a missing type in the create command's options interface. The full test suite (323 tests) passes, and tsc --noEmit is clean.

Upgrading

Already using gibil:

npm update -g gibil

Starting fresh:

npm install -g gibil
gibil init
gibil create --name my-project --repo https://github.com/you/repo --ttl 2h

Your existing servers are unaffected. The new TTL syntax kicks in on your next create or extend.

That's v0.3.2. Set a TTL that makes sense and stop worrying about it.