What LHV Forge is
An internal platform that generates, deploys and governs single-purpose internal
tools. You describe what you need, Forge builds it, and what comes back is a governed,
owned URL on forge.lhv.dev.
Nothing here is built yet. This page describes an intended platform, not one you can use. Everything is a proposal, including the templates, the deployment path and the boundaries in architecture.
Shipping an internal tool costs about the same whether it takes an afternoon or a quarter: a repository, a build, a pipeline, a domain, a certificate, a review, a named owner. So the afternoon-sized ones tend not to get built — they survive as a spreadsheet on someone's desktop, or a question the same colleague answers every Tuesday. Forge removes that fixed cost.
You describe
In plain language, in Claude Code: what the tool should do.
The agent builds
Picks a template, writes the application, commits it and runs the build.
Forge deploys
Provisions what is needed, deploys the artifact and returns the internal URL.
What it is not
- Not for anything customer-facing. Forge is inside the company, for employees.
- Not a replacement for engineering teams. Real products are still built by people who own them.
Where to go next
Use cases
A platform for building, deploying and running custom software and autonomous agents for internal use. What that covers in practice:
Internal applications
Dashboards, admin panels, custom UIs.
Workflow automation
Automate manual business and operational processes.
SaaS replacement
Build specialised functionality instead of buying it.
SaaS augmentation
Add custom functionality around existing systems of record.
Autonomous agents
Agents that independently perform internal tasks.
Integrations and glue
Connect existing internal and SaaS systems.
Prototypes and experiments
Quickly validate internal ideas.
None of it yet. The templates that would cover these arrive in the order set out on the roadmap.
Where it sits
Generated tools are one branch of lhv.dev — alongside the handbook, the
API documentation, the standalone index pages and the skills library, all feeding the
same knowledge graph.
lhv.dev landscape. Forge apps are one branch; background processing
and tagging turns everything published across them into the knowledge graph.
How to use it
The intended flow, once the plugin exists: Claude Code with the LHV Forge plugin, with no form to fill in and no ticket to raise.
-
Install the plugin
Once, per machine. It adds the Forge skills and the
forgeCLI to Claude Code.claude plugin install lhv-forgeForge acts on your behalf and records who requested every change.
-
Ask for the tool you need
Be concrete about what it does. Everything else is a follow-up question.
Create a site documenting LHV Forge for employees.Forge will confirm the application name and the template before it creates anything.
-
Try it
The agent serves the tool locally so you can use it before anyone else can. Check that it answers correctly — the numbers, not the code. Nothing gates the deploy, so this is the only look anyone takes.
-
Get your URL
The agent builds, uploads the files and returns the address:
https://home.forge.lhv.dev -
Keep iterating conversationally
Changes work the same way as the first request.
Add a Roadmap tab showing the order the templates arrive in. -
Check on it later
Ask about state instead of digging through consoles.
What is the deployment status of home? Show me its build logs from today. Who owns value-date-calculator?
How much you hand over is your choice
The path above is fully conversational, and for a fee calculator that is usually the right amount of involvement. It is not the only way in. An engineer can take the repository Forge created and work in it directly — read the diff, write the code, edit the manifest, run the build locally — and use the platform only for the parts that are genuinely tedious: the repository, the pipeline, the domain, the deploy and the audit trail.
Anything in between works too. Let the agent scaffold the application and then take over, or keep writing the code yourself and ask it only for the deployment. Both routes deploy the same way, so how much you delegate is a decision about your own attention rather than a condition of using Forge.
Good first requests
- A calculator that turns a rate table into a result — fees, FX, interest.
- A validator or formatter — IBAN, reference numbers, file layouts.
- A lookup or cheat sheet that today lives in a spreadsheet on someone's desktop.
- A dashboard over data you can export as a static file.
Not yet
Anything needing a backend, live LHV data, sensitive data, or a way to tell one employee from another. Ask anyway — Forge will tell you it is not supported rather than route it through a static page.
Templates
A template decides what an application gets and how long it lives. You do not choose one — Forge picks it from what you asked for — but it determines how your tool is built, deployed and constrained, so it is worth knowing which one you are on.
temporary-page First, not built
A page you make to answer one question, send to somebody, and forget. It deletes itself. Everything below is the proposed contract.
What it is for
- A specific discussion — the numbers behind one decision, laid out once.
- A quick exploration nobody needs to keep.
- Something to look at together in a meeting, instead of a screenshot in chat.
The URL
https://share.lhv.dev/7fq2p8
A generated slug, not a name you pick — there is nothing to agree on, and nothing
that has to stay free for later. It sits on share.lhv.dev, deliberately
apart from the tools on *.forge.lhv.dev, so a temporary link never
looks like a permanent one.
Layout
One file. Styles and script inline, so there is nothing to keep together.
index.htmlWhat it does not have
- No repository. Nothing is committed anywhere.
- No name, no owner, no registry entry.
- No history. Re-publishing replaces it; there is no previous version.
It deletes itself
Expiry is not a reminder, it is the storage. A lifecycle rule on the
share/ prefix expires every object 30 days after it was written, so a
page that nobody renews stops existing without anyone deciding to remove it.
The date is printed on the page itself. A link that has expired returns a plain message saying so and when — better than a 404, which reads as a mistake.
How it deploys
agent → s3://lhv-forge/share/7fq2p8/index.html → liveOne upload. No repository, no build, no pipeline, and nothing to invalidate. This is the smallest path the platform has, which is why it is the one to build first.
If it turns out to matter
Ask for it to be promoted. It gets a chosen name, a subdomain under
forge.lhv.dev, a repository and no expiry — at which point it is a
static-web-app and everything on that tab applies. Promotion exists so
that nobody has to guess, at the moment of asking, whether a page will still matter
in a month.
static-web-app First, not built
Everything below is the proposed contract — what a tool would have to stay inside for Forge to build, deploy and serve it without anyone touching AWS.
Layout
No build step. The directory is the artifact.
home/
├── index.html
├── styles.css
├── app.js
├── favicon.svg
└── images/
└── use-cases.png
Images go in images/. favicon.svg stays at the root, where
browsers look for it. Nothing here has a content hash in its name, so everything gets
a short cache lifetime — a folder that can be cached for a year needs filenames that
change when the bytes do.
Naming
The name is the subdomain, so it is DNS shaped: lowercase, digits and hyphens, no
underscores, unique across the platform. Say what the tool does rather than which
team owns it — value-date-calculator, not
payments-tool-2.
Renaming later changes the URL and breaks every bookmark and wiki link, so it is
worth a moment now.
Build
- The agent runs
build.commandin the tool's directory, nowhere else. - A failing build stops the deploy. Nothing is uploaded, and the previous version keeps serving.
- The build has no network access to LHV systems and no credentials. If it needs a secret to build, it does not belong on this template.
How it is served
Worth knowing precisely, because this is where static hosting usually surprises people.
| Where it runs | An internal Application Load Balancer inside the Forge VPC. It has no public address, so the tool is reachable over the corporate VPN and nowhere else. |
| Which tool | The hostname decides. iban.forge.lhv.dev is served from the
iban/ prefix in the bucket — so a new tool needs no load balancer
change, only a new prefix. |
| Directory URLs | / and /reports/ serve the index.html
in that directory. |
| Client-side routes | Unknown paths fall back to the app's root index.html, so
routers work without server config. |
| Caching | Whatever Cache-Control the deploy sets — short on
everything, since no filename carries a content hash. There is no CDN in front,
so a new upload is live immediately with nothing to invalidate. |
| Not available | Redirects, rewrites, custom headers, server-side anything. It is files over HTTPS. |
Running it locally
There is no staging environment, and nothing reviews the deploy, so local is the only place you can check your work before colleagues see it.
forge dev home
Serves the tool the way the load balancer will, including the directory-index and
fallback behaviour above — which open index.html does not.
Data
No integrations exist on this template, so a tool that needs data ships with it,
committed as a JSON or CSV file alongside the code. A value-date calculator is the
pattern: to work out when a payment settles it needs each country’s bank
holidays, so it bundles them as data/holidays.json and updates them
once a year.
Bundling has a real advantage — the data is versioned with the code like any other file — and a real cost: it is stale by design. Put the date in the file and show it in the UI, so people can see how old the numbers are instead of trusting them blindly.
How it deploys
One shared bucket, one prefix per application:
s3://lhv-forge/
home/
index.html
images/
value-date-calculator/
index.html
images/S3 holds built artifacts, not source. The bucket is private — the load balancer is the only way in, and it is reachable only over the VPN. Every static tool shares one bucket and one load balancer, routed apart by hostname; a hundred of them is a trivial scale for this setup.
A load balancer cannot read a bucket by itself, so a small function sits between the two and streams the object back. Invisible from a tool's point of view, but it is a moving part the platform owns rather than something AWS provides.
What you would get
- HTTPS on a
*.forge.lhv.devsubdomain. - Reachable by every employee on the corporate VPN, and by nobody else. No login, until SSO arrives.
- A deploy that leaves the previous version serving if the build fails.
What you are responsible for
- Whether the tool is correct. Forge deploys what you approve; it does not check your formula, your rounding or your rate table.
- Keeping bundled data current, and making its age visible in the UI.
- Never putting anything sensitive in the bundle — every file reaches the browser, including comments, fixtures and files you forgot you committed.
- Telling Forge when the tool is no longer needed, so it can be archived instead of quietly rotting on the network.
serverless-app-with-storage TBD
TBD. Next on the roadmap, not designed yet.
cloud-agent TBD
TBD. Not designed yet.
Architecture
Where the code lives and what separates Forge from the rest of LHV. Two boundaries carry the weight: a GitHub organisation and an AWS account. Proposals to argue with, not decisions — the open items are what needs settling before the first tool ships.
GitHub
- Repository creation is an organisation-level privilege — it cannot be given to a team, only to every member.
- A separate organisation makes membership the grant: you are added to
LHV-UK-Forge, and you can create tools. - The agent has write access, so it should be structurally unable to reach core repositories rather than configured not to.
Proposed
- One repository per tool, from a GitHub template repository — provisioning needs no
platform code, just
gh repo create --template. Still to be decided, and probably not for one-off pages, which do not warrant a repository each. - Organisation rulesets carry branch protection, so a new repository is compliant before anyone configures it.
Still open
- How membership is provisioned — with SCIM, joining is an identity change rather than a click, which weakens the onboarding argument.
- Licensing across two organisations, and cross-organisation package access.
- Who applies the fan-out: a template or dependency change has to reach every tool repository.
- What archives a tool nobody has opened in a year.
AWS
- The account decides the change-management regime. Inside a core account, every deploy inherits core banking's controls and the cost Forge exists to remove comes straight back.
- It is also the only boundary AWS genuinely enforces — everything finer is configuration that can be got wrong.
- Same Organisation, though: a separate one means rebuilding policies, billing, audit and identity.
Proposed
- Separate accounts in their own organisational unit, inside the existing Organisation.
- The agent deploys directly at first — no pipeline. Writing the deploy as a script keeps it reversible when CI is worth adding.
- No broad network route — a narrow path to approved APIs, because an account peered into core is not an isolated one.
- Short-lived credentials from Identity Center, so a deploy names a person and expires on its own.
- Service control policies as the backstop: no IAM writes, no audit tampering, regions restricted. These hold even when a role is misconfigured.
Still open
- Whether Identity Center is in place. If not, the first milestone needs long-lived keys on laptops — the one choice here that cannot be walked back.
- Which templates get a repository each, and which do not.
- The shape of the connection to core, and what stops it widening into general network access under time pressure.
- When a sensitive tool earns an account of its own.
- Bucket and load balancer naming. The domain is settled:
*.forge.lhv.devfor tools,home.forge.lhv.devfor this site.
Who can do what
| GitHub · tool author | Member: create repositories and push to them. |
| GitHub · platform | Owner: organisation settings, Apps, rulesets, deletion and visibility. |
| AWS · tool author | Publish the artifact to S3, with short-lived credentials. |
| AWS · platform | Provision infrastructure, IAM, account configuration. |
| Storage, integrations | Declared by the tool in its manifest, provisioned by the platform. |
The same rule in every row: anyone can publish, only the platform can change the shape of the environment.
Roadmap
Templates arrive in order. Each one is the smallest step that unlocks the next class of tool, and none of them starts before the one before it is carrying real applications.
NB. The order is proposed, not committed. Which template comes next depends on the ideas that come out of the discussion — if the tools people actually ask for need an agent before they need storage, the sequence changes. What is fixed is that they arrive one at a time.
-
temporary-pageFirstOne HTML file on
share.lhv.dev/<slug>, uploaded straight to S3 and deleted by a lifecycle rule 30 days later. No repository, no name, no owner — the smallest path the platform has, and the only one that needs no decisions first. -
static-web-appThenThe same infrastructure, made durable: a chosen name on
forge.lhv.dev, a repository, no expiry. This is the step that adds governance rather than capability. -
serverless-app-with-storageTBD -
cloud-agentTBD