Release
The last step in the life of a job: the compute held for the job returns to the shared pool and the meter stops. After release, nothing is owned and nothing sits idle.
· 2 min read
IN SHORT
Release is the final step in the life of a job on E31 Network. Once the output has been returned to the submitter, the compute held for the job goes back to the shared pool and the meter stops. The team pays nothing after release and owns nothing afterwards. What happens to staged data at release is a detail the program has not yet published.
Release is the last step in the life of a job: the moment the compute that was held for the job goes back to the shared pool and the meter stops. After release, the team owns nothing, pays nothing further, and has nothing sitting idle.
Why it matters
Release is what makes rented compute different from owned compute. With a server in a rack, finishing a job changes nothing about the cost; the hardware is still there and still being paid for. With a job on the network, finishing is the event that ends the spend. The idle time that follows a big run belongs to the pool, not to the team.
It also closes the accounting. A job that has been released has a complete record: compute held at a known point, run for a known duration, output returned, compute returned. The design intent is that what was held is accounted for at that point, in a form the team can read and keep.
How it works on E31 Network
In the designed flow, a job moves through submit, rent, run, output, and release. Release follows output: once the results have been returned to the submitter, the compute is released back to the pool and the meter stops. A team pays for rent and run; it does not pay for anything that happens after release.
Release is automatic in the sense that it follows from the job finishing. The team does not have to remember to turn anything off, and there is no idle instance waiting to be noticed on next month's bill. "Run the job, get the output, release the compute" is the shape every job is meant to take.
What happens to staged data at release is one of the things the program has not yet published. The design is that data is staged for the job and the job runs isolated from other jobs, but the specifics of retention and deletion after a job completes are not yet documented, and no claims should be read into their absence. That detail, like the question of where capacity comes from, is listed openly among the things not yet solved. The about page carries the current list.
Related terms
Questions this raises
- Do I have to release the compute myself?
- No. In the designed flow, release follows from the job finishing and its output being returned. There is no instance to shut down and nothing to remember; the compute goes back to the pool and the meter stops.
- Can I keep compute held between jobs?
- The design does not include that. Each job is held, run, and released on its own, and the network is for work that does not need to own or hold compute. Teams that want compute kept in their own rack have Czar, Element 31's appliance, as the sibling product.
- What happens to my data when the job is released?
- The design is that data is staged for the job and the job runs isolated from other jobs, but the retention and deletion specifics after a job completes have not been published. That is listed openly among the things the program has not yet settled, and no behaviour should be assumed.