How it works

A request that is checked first, a budget that is held, and a record of what it cost.

Kiln takes a job as a profile, a command, inputs, a size, and two limits. It refuses what breaks a rule, queues the rest in order, and keeps one record of each job's states, outputs, log, and cost that every page reads.

Illustration: a long brick workshop hall at night, a row of plain clay vessels waiting in line along a wooden shelf toward a brick kiln glowing with warm ember light.

Stages

From a request to a record

A job is in exactly one of eight states, and every change of state is written to its history.

A job that is canceled while it is queued is simply canceled. One that is canceled while it runs is stopped, and either way the record says who asked. Canceling a job that has already finished changes nothing.

Submitted
The request is checked for shape, sizes, and rules. A job that breaks one is refused with the field and the reason, and nothing is written.
Priced against the budget
The job's cap is added to the month's finished cost and to the caps of jobs still queued or running. If that passes the client's budget, the job is refused.
Queued
A job waits while its client is at its concurrency limit or the fleet's vCPU budget is in use. The queue page gives each job's place and reason.
Starting and running
The admission rule says which queued job starts next. A job that has started is starting, then running, and its timeline records each step.
Finished
A job ends in one of five final states: succeeded, failed, timed out, capped, or canceled. A failed job carries a class and a reason.
Costed
Its billed seconds and cost are worked out from the price table, and its outputs are listed with their checksums.

A job that is running: the status Running, a timeline that ends at Running, the cost not yet billed, the cost cap and what it pays for, and the timeout. — A running job. The cost reads Not billed yet until it stops.

Rules

Refused before it is written

Kiln checks a request against its rules first, so a refused job costs nothing and leaves no record.

A repeated submission with the same idempotency key and the same request returns the job that already exists. The same key with a different request is refused as a conflict.

What a request may hold
Field	Rule
Command	1 to 64 arguments, each up to 4,096 characters
Inputs	Up to 64 sources, and no two files at the same path
Environment	Up to 32 variables, 32 KB in all, names in capitals; names that look like secrets are refused
Labels	Up to 16 pairs, for filtering and for the client's own bookkeeping
Size	One of six classes, or a combination Fargate accepts
Timeout	At least 60 seconds, and no more than the profile and the client allow
Cost cap	At least the cost of the minimum billable run at that size, and no more than the client's maximum

Cost

Sized and priced like Fargate

A job's cost is worked out the way Fargate bills, from numbers kept in the ledger.

Cost is the billed seconds over 3,600, times the hourly cost of the task: its vCPU at the vCPU rate, its memory in GiB at the memory rate, and any storage above Fargate's default 20 GiB at the storage rate. Billed seconds run from the start of the image pull to the stop, and are never fewer than 60.

The rates are rows in a dated price table, each with its architecture and where it was read. A job keeps the row it was priced on.

Size classes and their hourly cost
Class	vCPU	Memory	Per hour, ARM64
xs	0.5	1 GiB	$0.0198
s	1	2 GiB	$0.0395
m	2	4 GiB	$0.0790
l	4	8 GiB	$0.1580
xl	8	16 GiB	$0.3160
xxl	16	32 GiB	$0.6320

The size is chosen with its hourly cost beside it.

Queue

A budget that is held, and a queue that says why

Limits are checked in two places: when a job is submitted, and when it is admitted.

Every client has a monthly budget. A job is refused if its cap would pass it, counting what finished jobs cost and what queued and running jobs could.
Every client has a concurrency limit, and the fleet has a budget of running vCPU. A job past either one waits.
Within a client the queue is first in, first out. Across clients it takes turns, so one client's backlog cannot starve another.
The reason shown for a waiting job comes from the same function that admits it.

The queue: a meter showing 18 of 48 vCPU in use, running jobs grouped by client, and two queued jobs, each with its place in line and the reason it waits. — The queue, with a reason for each waiting job.

Spend and reservations against each budget.

Records

What a job leaves behind

Everything a page shows about a job comes from one record.

A failed job's class is one of six: it could not start, its inputs could not be staged, its command exited non-zero, its outputs could not be stored, its task was lost, or Kiln itself erred.

What the ledger keeps for a job
Record	Holds
The job	Client, who submitted it, profile, image, command, labels, size, limits, state, failure, exit code, and cost
History	Each change of state, with the time and what caused it
Attempts	Each try to start the job, and why one stopped
Inputs	Each input's path, size, and SHA-256
Outputs	Each output's path, size, type, and SHA-256, with a preview where a browser can show one
Log	The text each of the four logs wrote: main, stage-in, stage-out, and watchdog