Frequently asked questions

Envor is an environment orchestrator for non-production cloud: it keeps each of your dev, staging, QA, and performance environments in the state it should be in right now, following a weekly schedule you define in your own timezone.

The states are yours to define, and switching off out-of-hours is just the best-known use case: an environment can equally step down to a Reduced profile instead of off, hold a Maintenance state overnight, or, like an expensive performance environment, stay down by default and run only when someone puts their name to a reason to spend, for exactly as long as they asked.

The people who use an environment control its schedule themselves, without tickets, and for most teams the result is a non-prod cloud bill that goes down and stays down.

A category you may not have met by name, because until recently teams could only build one themselves. An environment orchestrator manages a whole environment (its services, their dependencies, and the states they should hold) as a single unit: it knows what state the environment should be in at any moment, drives it there in the right order, verifies it actually arrived, and governs the exceptions so they expire instead of accumulating.

If you've ever wired together cron jobs, downscaler annotations, a runbook for start-up order, and a list of who's allowed to keep what running overnight, you've built one by hand. Envor is that, as a product.

Teams running persistent, multi-service non-prod environments: the large staging environment, the data-heavy integration environment, the licensed or legacy stack that can't simply be destroyed and recreated per branch. It's strongest where start-up order matters and where security review is a real gate. If your whole non-prod estate is ephemeral and built per pull request, you probably don't need us; the saving there comes from not having the environment at all.

You give each environment a weekly pattern of named states; the common starting point is two, up during working hours and down outside them. Schedules live in your own timezone and adjust themselves across daylight-saving changes, so 9am means 9am all year. At each change, Envor works out what every service in the environment should be doing and drives the environment there. A schedule can also say "be ready by 9:00" rather than "start at 9:00": Envor learns how long your environment really takes and starts it early enough to be there on time.

Almost everyone has, and it always dies one of two ways. Either one bad morning (an environment stopped mid-job, or brought back broken and in the wrong order) gets the schedule ripped out, or exceptions pile up until nothing is scheduled any more, because "keep my environment up tonight" meant a ticket and a wait.

Envor is built against both failure modes: transitions are ordered, verified, and timed from how long your environment has actually taken, so mornings stay boring; and overrides are self-service, time-bounded, and expire on their own, so an exception can never quietly become the new always-on. The number we ask to be judged on isn't the percentage turned off in week one; it's still saving, months later.

A cron stop/start treats each resource on its own and fires and forgets: it doesn't know the database must be up before the API, whether anything actually started, or that someone is mid-test right now.

Envor treats the environment as one system: transitions run in dependency order (reversed on the way down), are confirmed rather than assumed, and are timed from how long your environment has actually taken before. When the schedule needs bending, that's a self-service, expiring override rather than an edit to the crontab. That difference is why we call it an environment orchestrator rather than a scheduler.

Any you define. A state names what every service in the environment should be doing while the environment holds it, so beyond up and down you can shape: Full, Reduced, and Minimal profiles for different times of day, or a Maintenance state for patch windows.

It also inverts cleanly: an expensive performance environment can sit on a schedule that never turns it on, waking only for a time-bounded, attributed override (a team books it for the load-test week, the spend is priced and named, and at the end of the span it goes back down on its own).

Timing and retry behaviour are declared per transition, because a cold start, a warm scale-up, and a trim are genuinely different journeys, and Envor learns the real duration of each.

Anything your side can act on. Envor deliberately doesn't touch your infrastructure: it publishes signed change events to a delivery topic, and a subscriber you own and run does the acting with your own permissions. For Kubernetes there's a first-party actuator (EKS, GKE, AKS) that applies changes and reports back with full fidelity.

Beyond Kubernetes, you bring your own subscriber over a documented contract: a function driving an autoscaling group, a workflow starting and stopping a database, or anything else you can script.

One specific to know: delivery itself currently rides AWS SNS, so the subscription that receives instructions lives in an AWS account you own, even when the workloads being driven are elsewhere.

Most teams arrive from one of three shapes. Free in-cluster downscalers do fixed sleep windows per workload well, but exclusions are unbounded annotations, nothing is ordered or verified, and there's no accounting, which is why their savings tend to erode. Commercial auto-stopping tools detect idleness and stop resources, which takes credentials into your accounts and a guess about what idle means; the guess is why teams don't trust them with anything stateful or multi-service. Cluster sleep modes park a whole cluster on a timer, at one grain.

Envor's ground is different: whole environments coordinated and confirmed as systems, overrides that are governed rather than annotated, and no access into your cloud at all. If a per-workload timer is genuinely all you need, the free tools are good at exactly that.

That depends on how much of your estate sits idle out of hours, so we'd rather measure your number than quote an industry one. The arithmetic is strong: an environment used twelve hours a day on weekdays is idle for about two thirds of the week, which is where the textbook figure of around 65% of a scheduled environment's compute comes from. Envor prices your actual state history against what always-on would have cost, so the savings you report are measured from your own environments, not projected from a slide.

With the savings view, which is built for exactly that conversation. It shows what your environments actually cost over the period, what the same period would have cost unmanaged, and what your own schedule alone would have cost with no exceptions; every override sits between those lines with its own price, owner, and reason. Because every figure is computed from the recorded history of what Envor did and confirmed, the report is reproducible, not a one-off estimate.

Each one is priced individually, with its owner and justification attached, so a typical month reads something like "overrides cost £180; unmanaged, these environments would have cost £4,200". That framing turns overrides from an invisible leak into a controlled release valve you can watch working, and if override spend ever starts creeping toward the baseline, you see it in the trend rather than in a surprise bill.

Yes. When you ask to keep an environment up or wake one early, Envor shows the estimated cost of that specific span before you confirm it. The estimate uses the same rates and the same engine as the savings reporting, so the number you saw before committing and the number attributed to you afterwards agree.

They hold, by design rather than by vigilance. The schedule is the resting state: an environment nobody is thinking about simply follows it, and every deviation has an end date, so neglect trends toward savings instead of overspend, the opposite of the usual cloud default. The trend view still shows realized savings against the theoretical ceiling, so if exceptions ever do start eroding the number, you see it months before it matters.

The rates are yours. Your team measures what each service costs per hour in each state (you hold the billing access; Envor doesn't) and records it as a rate card. Envor multiplies those rates by its own recorded timeline of what state everything was in, and reports alongside how much of that timeline carried a rate, so an unpriced service shows as a visible gap, never a silent £0. It's an estimate by construction, exactly as good as your measurements, and it keeps the boundary intact: no billing reader, no cloud access.

The 9am failure is what a blind scheduler does, and each of its causes has a designed answer. Envor starts early enough, because it learns how long your environment really takes and works back from when you need it. It starts things in the right order, waiting for each dependency to be confirmed in place. It checks the environment actually arrived, rather than assuming. And if someone is mid-run when a change is due, their hold makes the change wait.

When something does fail, Envor says so immediately and visibly, which is the difference between a fixable morning and a ripped-out schedule.

You declare the order as dependencies: the API needs the database up before it starts; the database must not stop until the API has stopped. Envor evaluates that graph for the state being entered, so shutdown order is naturally the reverse of start-up, and each service moves only once the services it depends on are confirmed where they need to be. It's a confirmed handoff, not a configured delay: a slow database start holds the API back for exactly as long as it actually takes.

Because the thing doing the work tells it. Your actuator reports progress and then the outcome of each change, and an environment can also declare a final health check that runs after everything has converged, so "done" can mean "verified serving", not "commands sent". Where no report arrives, Envor judges the silence honestly against the time budget you declared for that transition, and records the result as unconfirmed rather than dressing it up as success.

It gets retried within a budget you declare per transition, and you also declare what the failure means: some services are optional (the environment completes without them), some degrade it (it comes up flagged), and some fail it (the whole environment retries). If the budget runs out, the environment doesn't thrash: it either stands where it got to, visibly degraded, or withdraws to the coherent state it left, whichever you chose for that environment. The next scheduled change tries again fresh, and everything that happened is on the record.

If they've placed a hold, nothing: the shutdown waits until the hold lifts. A hold is "do not disturb" for an environment or a single service, and it's for machines as much as people: place one in seconds from the console, or have the deploy job, data load, or test run place its own. Every hold carries a reason and expires on its own, so protection during a run never becomes a permanent exception. The stopped-out-from-under-me incident simply doesn't have a path to happen.

No, deliberately. Detecting usage means watching your workloads, and Envor never looks inside your cloud; that's the access boundary that keeps your security review short. Instead, being in use is something you say: a hold placed by a person in seconds, or by the pipeline running the job. It's a trade we make openly. Detectors guess, and guess wrong in both directions: the load test that looks idle from the metrics gets killed, and the forgotten heartbeat keeps an environment up for a year. A hold is explicit, attributed, and expires on its own.

It's safe before it has learned anything. The time budgets that judge success and failure are the ones you declare per transition, and the learned estimate never moves them. What learning sharpens is scheduling: until Envor has seen enough confirmed runs of a transition, it plans using your declared ceiling, which just means starting conservatively early; as real durations accumulate, start times tighten toward what your environment actually does. So the cost of the unlearned period is a few unnecessarily early starts, never false failures, and it fades over the first weeks of ordinary running.

And you can watch it learn: the plan for any transition shows the timing it will use for each service and how many confirmed runs that rests on.

Envor won't see it: it never observes your cloud, so its picture comes from what it asked for and what your actuator confirmed. Keeping reality at the commanded state is the actuator's job. The Kubernetes actuator reconciles continuously, so a hand-scaled workload is put back; a simpler subscriber corrects at its next instruction.

If Envor's picture is ever genuinely wrong after something exceptional (a restore, a rebuild), an admin can assert the true state, and the record shows who did. That's the access boundary's trade: Envor can't notice drift on its own, because it cannot watch your infrastructure.

Nothing you'd notice, which is the point. Schedules are civil times in a named timezone, not UTC offsets, so a 9am start is 9am in your zone all year, and each environment can keep its own zone.

The two odd nights a year are settled by one rule rather than left to the platform: a time that spring-forward skips runs at the moment the clock jumps to, never earlier; a time that fall-back repeats runs once, at its first occurrence. Every boundary fires exactly once, the resolved instant is shown on the timeline ahead of time and recorded once it has happened, and a timezone Envor can't load is rejected when you write it rather than quietly falling back to UTC.

You can reconstruct it completely. Every action Envor took is on a ledger: what was asked, by whom or by which schedule, what the actuator reported back, and when. Every decision is explainable from your configuration plus the clock; there's no model guessing and no black box. That matters because trust in scheduling dies on unexplained mornings: after a bad one, you can show your team exactly what happened, and fix the configuration rather than the confidence.

Nothing moves. Envor only ever sends instructions; it holds nothing in your infrastructure, so if it's absent, nothing actuates and your environments stay exactly as they are.

That bounds the worst case: an outage can never break an environment; the most it costs is a scheduled change that waits, typically a morning bring-up, until Envor is back or you make the change yourself. Your actuator is yours, so making it yourself means setting its desired state by hand (for the Kubernetes actuator, the state it holds rather than the workloads beneath it, which it would put back), and when Envor returns it converges everything to where the schedule now says.

Two design choices narrow it further. The service running your schedules is separate from the portal and billing and depends on neither at runtime, so an outage there never touches orchestration. And delivery is built for an unreliable world: instructions can arrive late, repeated, or out of order and your actuator still ends up in the right place, because it reconciles against the current desired state rather than obeying messages blindly.

Yes. From the console you pick the environment, the span, and a reason, see what it will cost, and confirm; the environment stays up and comes back onto its schedule when the span ends. No ticket, no waiting for a platform engineer, nothing to remember to undo. What you can control is bounded by your role, so self-service doesn't mean a free-for-all.

You can look rather than guess. Every environment has a forward timeline: the state it will be in, minute by minute, days ahead, with the schedule, any overrides already in force, and any holds shown with who placed them and why. For the transition at hand there's also a plan: which services move in what order, and when the environment will be settled, using timings Envor has learned from your own history rather than a fixed allowance. The same timeline runs backwards, so "did it come up on time last Tuesday?" is a look too.

A Saturday load test or a Monday morning demo becomes a check, not a hope, and if the answer is no, the override that fixes it starts from the same view.

Yes. A wake is a short, named override to a running state: the environment comes up in its proper order, with a plan that tells you when it will be ready, and goes back down when the override expires. Because a wake is the same governed act as any other override, it's attributed and priced like one, rather than being an anonymous side door.

Nothing bad: it undoes itself. Every override carries an expiry from the moment it's created, so forgetting is the safe case: the schedule simply reasserts itself when the span ends. There's no way to keep something on indefinitely by accident; extending is another named, bounded decision.

Yes, and it's one of the most satisfying setups: give the environment a schedule that never turns it on. When a team needs it (the load-test week, say), they book it: an override that follows a working schedule for exactly that span, with their name and reason on it and the cost shown up front. When the span ends, the environment goes back down by itself. Spending becomes a deliberate, attributed act, and idle-but-paid-for stops being the default.

Structure, not discipline. Every exception is scoped to an environment, time-bounded with a mandatory expiry, attributed to a person or a job, justified, and priced; there is no unbounded "just disable it" anywhere in the product. That makes the classic decay pattern (carve-outs accumulating quietly until the tool saves nothing) structurally impossible, and the monthly view prices the exceptions against the baseline so the trend is watched, not discovered.

Four roles. Readers see everything and change nothing. Operators drive day-to-day control: holds, wake-ups, keep-ups. Agents are machine credentials for pipelines, limited to placing and lifting holds. Admins manage the configuration, credentials, and the audit trail. Changing what an environment is (its services, states, and schedule) is a reviewed configuration change, not something an override can reach.

Yes: it's the same hold a person places, made under a machine credential with narrow rights: the job places it when it starts and lifts it when it finishes. Overlapping holds under one reason simply extend the protection, so retries and long stages don't fight each other. If the job dies without cleaning up, the hold's expiry catches it: the protection lapses on its own instead of pinning the environment up forever.

A job can also read the environment's timeline before it runs, so a nightly stage aimed at a window the environment is down in is caught when the pipeline is written, not when it fails.

None. Not a role, not a key, not read-only. Envor publishes instructions to a delivery channel, and your own subscriber, running in your account or cluster with your own permissions, does the acting. There are no credentials to hand over, so there are none to leak, rotate, or explain to an auditor.

No agent of ours. What runs inside your perimeter is an actuator, and it's yours in every sense a security review cares about: open source, in your repository, pinned to the version you chose, readable line by line, holding only the permissions you granted it, and talking outwards only (it subscribes, reports outcomes to a callback you can read, and accepts no inbound connection).

That puts it in the class of software platform teams already run on those terms, like cert-manager or external-dns, not the class of vendor agents with root and an auto-updater. The wiring is yours too: it goes in through your own Terraform and your own review, and comes out the same way.

The direction of trust is always you toward Envor, never the reverse. Envor publishes each environment's instructions to a topic in its own account; you're granted a subscription to it, which is the only cross-account object in the whole arrangement, and it's one you own. Your subscriber receives the instruction, acts with its own least-privilege permissions, and reports the outcome to a callback URL carried in the message. At no point does anything reach from Envor into your account.

Two independent ways. A topic can opt into signing, in which case every message carries a signature you verify with a key that landed in your own secret store at provisioning time. And every command carries a callback that doubles as a check: before acting, your actuator can ask "is this instruction still current?", which a forged or stale message cannot answer, because only Envor can mint the token that makes the question work.

Bounded by construction. Envor holds no credentials into your accounts, so a compromise gains no path to read or touch your infrastructure directly. The only lever an attacker would hold is the instruction channel you already subscribed to, and that channel can only ask for the states you declared: your actuator maps named states to actions and does nothing else. The worst case is unwanted transitions between states you defined, visible on the ledger as they happen; never arbitrary access to your cloud.

From the Terraform plan, mostly. Adopting Envor is an apply, and the plan shows precisely what's being granted: no IAM roles for Envor, no stored credentials, one subscription you own pointing at a topic. The no-access claim isn't something to take on trust from a vendor page; it's verifiable in the diff your own change process already reviews.

Envor stores what you declare (environments, services, schedules, rates), the operational record of what it asked for and what was confirmed, and your account and access data. It never reads from your cloud, so it holds no workload data, no billing data, and no telemetry from inside your environments; the record is entirely about what Envor itself did. Each customer's data is isolated per tenant.

Envor is hosted in the UK, and the only data that leaves it is the instruction itself, delivered to a subscription you own, in the account and region you choose.

Signing in to the console is through your identity provider: Envor authenticates people via OIDC, so your existing joiner-and-leaver process governs who can reach it, and access ends when the identity does.

The first environment is an afternoon, not a project. Adoption is one Terraform apply (the environment's description and its delivery wiring) plus one actuator install, a Helm release on Kubernetes. From there, the honest measure is the one we suggest you run: pick two or three environments, note the bill, switch the schedule on, and compare.

Three things, none of them access. A description of each environment (its services, the states you want, and anything order-dependent) written as code; most of it reduces to a module call, and it's the one piece of real work. Somewhere for the actuator to run, on your terms: your cluster, or a small function in your account, installed through your own Terraform and your own review, with nothing of ours you can't read. And, if you want cost figures, the hourly rates you measure for your own services.

Barely. Developers and testers keep their tools and gain a console where their environment's schedule is visible and theirs to bend within guardrails. The platform team declares environments in the Terraform it already writes, and stops brokering keep-it-up requests by hand. The main change is subtraction: the ticket queue for environment exceptions goes away.

Yes, first-class. Environments, services, schedules, and delivery topics are resources: reviewed in pull requests, drift-detected on every plan, importable if you're bringing existing config under management. One apply composes Envor's configuration with your own cloud resources: the queue, the subscription, and the actuator install. Deliberately not in the provider: overrides and holds, which are runtime decisions with expiries, not law for the repo; the split is what keeps exceptions from calcifying into config.

It's a small component you install in the cluster with Helm. It subscribes to your environments' topics, maps each named state onto your workloads (replica counts, suspend, autoscaler envelopes) through bindings you declare, reconciles the cluster to what's asked, and reports progress and outcomes back. It's built to be legible from inside the cluster: what it thinks, what it last did, and why are readable with kubectl, without touching Envor. It works the same on EKS, GKE, and AKS.

Yes, against a documented contract, and it's deliberately small: subscribe to the topic, act on the instruction, optionally report back on the callback URL. A few dozen lines of function driving an autoscaling group is a real actuator. Confirmation is optional: a subscriber that never reports back still works, with Envor falling back to the time budgets you declared instead of confirmed outcomes.

No. An environment can start as a single unit: one state, one instruction, one actuator doing whatever "up" means for it. Services are an opt-in refinement you add where ordering, verification, or per-service timing earns its keep, and you can deepen the model environment by environment as the value shows up.

Yes, and it isn't a side door: everything the console does rides the same HTTP API, authenticated with API keys carrying the same roles as people. Writes are idempotent and safe to retry, which is what the Terraform provider is built on; reads cover live status, plans, history, costs, and a followable event feed.

A flat monthly subscription, self-serve, with a ladder of plans that differ by capacity rather than features. You pick a plan sized to your estate, pay monthly, and change or leave whenever you like; current prices are on the pricing page. The pricing intent is simple: Envor should cost an unremarkable fraction of what it saves.

Yes: the free tier is the trial, and it isn't a demo build. Every capability is in it (the same scheduling, verification, overrides, and reporting), gated only by capacity, so you can prove the product on a small real estate for as long as you like before paying anything.

Capacity, never capability. Paid plans raise how much estate and how many people: environments, services, seats and keys, standing overrides, history. Nothing about safety, verification, ordering, or governance is ever behind a higher tier, because selling a less-safe version of a product whose job is to be trusted would be self-defeating.

Each plan carries explicit quotas (environments, services, keys, standing overrides, live connections) and you can see your headroom against them. Hitting one is a clear, immediate answer at the moment you try to exceed it, never throttling or silent failure, and moving plans is the remedy. Deleting things frees room straight away.

Cancel from the account page, any time. Nothing dramatic happens to your infrastructure: Envor only ever sent instructions, so when it stops, your environments simply stay as they are; there's no teardown and nothing to unwind.

The off-ramp is real, not theoretical: your actuators are yours, running in your accounts against a documented message contract, and your environment model lives in your own repo, so replacing Envor means replacing the thing that sends the messages, not rebuilding your actuation or your estate.

Account data is retained for a recovery period after cancellation, then deleted.

Envor is built and run by Coniston IT, a UK software company.

It was designed by Jonathan Heather, our Chief Engineer, and draws on close to a decade of platform engineering for our clients. The same challenge came up in estate after estate: non-production environments paid for as if they were production, when the work in them keeps office hours. Every engagement grew its own partial fix, usually a cron job, and he watched the same ending more than once: the day it got in someone's way, disabling it was the accepted workaround, and expensive environments were left running all weekend. None of those fixes was the whole answer. Envor is that answer, designed once as a product rather than rebuilt for each client.

Every plan includes support through the portal. The product is also built to keep support conversations short: the ledger records exactly what happened and why for every action ever taken, so most "what did it do last night" questions answer themselves from the record rather than from a ticket.

Not yet. ISO 27001 is the first we'll pursue, and it starts immediately after public launch rather than during the design-partner phase; we'd rather say that plainly than describe a programme that hasn't begun.

Two structural points carry weight in the meantime: Envor holds no access to your cloud accounts, so the usual vendor-risk questions about credential handling largely don't arise; and that claim is verifiable from your own Terraform plan rather than from our paperwork.