Jenercode manages the infrastructure, watching the logs and shipping the fixes. What sits in that account stays yours — your data, your running application and the production code behind it — held under your own agreement with AWS, not through us.
Hosting with Jenercode is optional. You own the code either way, and you can take it to your own infrastructure whenever you want. What that looks like →
In your name, on your card. We never sit between you and AWS, so there is no margin on your infrastructure.
You see the full permission list — what the role can do, and what it cannot — before anything is created. Nothing happens until you accept, and what you accepted is recorded.
One click opens CloudFormation in your account, with our template and a one-time External ID already filled in. Create the stack; we take it from there — nothing to copy back.
Every build is compiled, security-scanned and run against its tests before it is promoted. Then it runs in your account, on your terms.
Nothing here needs a platform engineer. If you can create an AWS account and click Create stack, the rest is done for you.
That role is the whole of our access. It is enough to run the infrastructure your application sits on and to act on what its logs say — and deliberately not enough to reach your money or your account. You see this same list in the product, in full, before you authorise anything.
Every “cannot” here is an explicit Deny, not a promise. You read this list in the product before you authorise anything, and it is written into the policy in your own account afterwards — where you can check it, and delete it.
A fresh AWS account has no guardrails on it at all. These go in the moment the connection is verified — the same way, on every account, whether or not anyone thinks to ask for them.
An alarm on estimated charges is installed before anything else runs, so a misconfiguration on a brand-new account cannot quietly spend money for a month before anyone notices.
A locked-down bucket in your own account that build artefacts and deploy logs land in — so the record of what was deployed, and when, lives with you and not only with us.
CPU pressure on compute and database instances, and error spikes at the load balancer. Standard alarms, installed identically on every account, so there is nothing to remember to configure.
Jenercode reads those alarms and the logs behind them on a schedule. A defect or a missing patch is fixed from there without waiting on you; anything that would change what the application does is raised inside the project instead. You find out in the same place you build and change the application.
A hosted application stays connected to the platform that built it. What the people using it report comes back as a change to the specification and the code — not a pile of tickets nobody can act on.
Every project gets its own board at its own address. Give the link to the people who actually use the application — staff, clients, testers — and they raise what they find without needing a Jenercode account or an email thread.
Reports arrive typed and severity-graded. A defect or a security issue is remediated automatically — it is not a decision anyone needs to make, and waiting on a triage meeting to fix something that is plainly broken helps nobody.
A new feature is different, whether a user asked for it or Jenercode recommended it: it changes what the application does and what it costs, so it waits for your project team. Approve it and it goes to the build with the project’s full context behind it — the specification, the architecture, the existing code — as a change to the application rather than a patch bolted onto the side of it.
An automatic bug fix and an approved feature take the identical route out: compiled, scanned, tested against the deployed site, then released. The same pipeline as the original build, so a one-line fix gets the same scrutiny as a first launch — which is what makes fixing bugs without asking you safe to do.
The application keeps evolving. Because the specification stays the source of truth, a system that is two years old is still coherent, still documented, and still yours.
You pay AWS directly for exactly what you use, on your own payment details. Our role carries no billing permissions at all. Your data sits in your account, in the region you chose.
Our access is a single role your own CloudFormation stack created, scoped to infrastructure and logs and locked to a one-time External ID. We hold no long-lived keys — every call is a one-hour session obtained by assuming that role.
Delete the jenercode-connect stack in your own console and our access is gone. You do not need to ask us, and nothing of yours goes with it.
Take the codebase to your own repository and run it anywhere. Hosting with us is a convenience, never a condition of ownership.
Plenty of teams already have a platform group, a landing zone and a deployment pipeline they trust. Nothing about Jenercode asks you to replace them: what you own is a conventional, documented codebase, not a package that only runs on our infrastructure.
What you give up is the automation on this page. The provisioning, the guardrails, the health monitoring and the feedback loop become yours to run — a fair trade if you already run them well, and a real cost if you do not.
Your own AWS account, set up and looked after for you — or your own infrastructure, with the code handed over. Both are supported, and the choice stays yours.