A KeyVault of your own

Up until now, Fkh has been very deliberate about not storing humanly created secrets. As I described in The security model of Fkh, everything runs on managed identities, federated credentials and just-in-time access - and that principle hasn’t changed.

What has changed is that there are situations where you genuinely need a secret. A container admin password is the obvious example, but there are plenty of others - license references, tokens for third party services, connection details you don’t want to type over and over again.

When you update to the latest preview, Fkh now deploys an Azure Key Vault as part of your deployment. Just like everything else in Fkh, it lives in your own Azure subscription, and that is where your secrets are stored - under your control.

Standard or Premium

The Key Vault comes in two flavours, and you get to choose which one you want when you deploy:

• Standard (the default) - a standard, software-protected Key Vault. This is more than enough for the vast majority of scenarios.
• Premium - backed by hardware security modules (HSM) for those who have compliance or policy requirements that mandate HSM-protected keys (needed if you want to use this for code signing).

You control this with a single configuration option in your deployment (keyvault_sku). If you don’t set anything, you get Standard, so there is nothing you have to do to get going.

Because it is RBAC-enabled and wired directly into the Fkh backend, you never have to hand out access to the Key Vault yourself. The backend authenticates and authorizes you exactly like it does for every other operation - GitHub for who you are, GitHub team membership for what you are allowed to do.

Managing secrets from VS Code

Once you are on the latest preview, you get three new operations to work with secrets, and they are all available right where you already work - in VS Code:

• List secrets - see which secrets exist
• Set a secret - create, update or remove a secret value
• Get a secret - read a secret value back

These are just Fkh commands, so you invoke them the same way as everything else - from the command palette or the Fkh views. When you set a secret, the value is stored in the Key Vault in your subscription; when you read one back, the value is fetched on demand.

Secrets can be your own personal secrets or shared across everyone in your organization, so admins can maintain a common set of secrets while individuals can override and/or have their own. When a secret is looked up, Fkh checks your personal secrets first and falls back to the shared ones.

…and from the CLI

If you prefer scripting - or you want to use secrets from a pipeline - the exact same operations are available in the Fkh CLI. As I explained in The Fkh CLI, the CLI and VS Code are just different faces on the same backend, so nothing new is happening here - it is the same functionality, exposed on the command line.

A few examples of what that looks like:

# List the secrets you have access to
fkh listsecrets

# Set (create or update) a secret
fkh setsecret --name adminPassword --secret (Read-Host "adminPassword")

# Read a secret back
fkh getsecret --name adminPassword

In a future version, you will also be able to use this KeyVault for your AL-Go repositories and have one single source for all your secrets, right in your own Azure Subscription.

Using secrets as values for parameters

Storing and reading secrets is useless in itself, you need to be able to use the secrets. This first version wires secrets into the parameters of the operations you already run.

Take CreateContainer as an example. Creating a container needs an admin password, and until now you had to provide it every time. With secrets in place, you can store the password once and then reference it in the parameter instead of typing the value.

Anywhere a parameter value is written as @secretName@, Fkh substitutes it with the corresponding secret from the Key Vault before the operation runs. So instead of putting a real password into the adminPassword parameter of CreateContainer, you simply put:

@adminPassword@

Fkh resolves @adminPassword@ to the stored value at the moment it creates the container. The same mechanism works for any parameter, not just adminPassword.

Defaulting parameters with secrets

As explained in Creating containers in VS Code using Fkh you can default parameters for container creation and also here, you can use secrets. If you specify:

"CreateContainer.adminPassword": "@adminPassword@"

In your AL-Go settings, the admin password will now be read from the keyvault and inserted right into the Create Container dialog and you can press the Show/Hide button to see the value.

Note: If you haven’t set up the secret, the mandatory field will be there for you to fill out.

The foundation for more

As handy as list/set/get and parameter defaulting are on their own, the most interesting part is what this enables. Having a proper, trusted Key Vault in every Fkh deployment is the foundation for a couple of things I have on my mind:

• Secrets handling for AL-Go for GitHub - letting Fkh act as the secure store that AL-Go for GitHub reaches into for the secrets it needs, so your pipelines can get what they need without secrets being copied around.

• KeyVault access for containers - giving containers a controlled way to reach into the Key Vault, so an app running inside a container can consume secrets the same secure way. This actually comes from Issue 69.

And probably more scenarios will pop up. Neither of those is in this preview - this post is about the foundation that makes them possible. Whether and when they show up depends a lot on what partners and customers using Fkh actually need, so if this is interesting to you, let me know.

To use AI or not to use AI, that’s the question

During development of Fkh, I obviously use AI. I could have asked AI to solve Issue 69 - and I am fairly convinced that it would have found a way to fix that, but I am also convinced that AI wouldn’t do this the way I wanted it done, using a sound and reusable architecture, which can be used as the foundation for other things. AI has never before written a tool like Fkh - and it will probably never do so. It doesn’t understand the use cases, nor the complexity of this tool.

It isn’t any different from asking a very skilled junior developer with no experience to build a tool like this - they will fail.

I use AI as my team of engineers, who implement the features I have architected and described.

Update to the latest preview to try it out, and take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

Which tasks should I delegate to an AI agent – and which ones should I keep, at least for now?

What follows is a framework for answering that – simple enough to keep in your head, but sharp enough to actually change your decisions. It has four dimensions, each with a question behind it, a way to score them, a rule that ties them together, and three outcomes it produces.

Why not just “use AI for everything”?

The naive approach is: try to delegate everything, and keep whatever fails. That works, sort of, but it’s expensive and occasionally dangerous. Some failures are cheap and obvious – the agent writes a bad paragraph, you notice, you rewrite it. Other failures are silent and costly – the agent confidently produces a number that is wrong, nobody checks it, and it ends up in a report that drives a decision.

The reason “use AI for everything” is a bad rule is that the tasks where delegation goes wrong are exactly the tasks where you can’t easily tell it went wrong. So we need something better than gut feeling. We need a way to look at a task before we delegate it and ask: is this a good candidate, a candidate with conditions, or something I shouldn’t hand over yet?

That’s what this framework does.

The core idea: four dimensions

Every task can be scored along four dimensions. Each dimension answers exactly one question:

A task can score brilliantly on one and terribly on another, and that’s precisely why you need all four – any single one of them, on its own, will mislead you.

For each dimension I’ll give the underlying question, the sub-questions that let you score it, and what a high and a low score actually look like.

Dimension 1 - Economic attractiveness

The question: Is it worth delegating?

This is the dimension people usually start with, and it’s the easiest to feel intuitively. If a task is rare, trivial, and takes you ten seconds, there is no point building an agent for it. If a task is frequent, tedious, and eats hours of expensive human attention every week, it’s screaming to be delegated.

Sub-questions that let you score it:

A high score looks like: a frequent, time-consuming, tedious task currently done by people whose time is better spent elsewhere, where doing more of it (or doing it more consistently) would genuinely help – and where the cost to set up and run an agent is comfortably outweighed by that value.

A low score looks like: a rare, quick, low-effort task where the setup cost of delegation will never pay itself back. These aren’t unsuitable for agents – they’re just not worth the effort.

Important: a high economic score is what makes a task interesting, but on its own it tells you nothing about whether you should delegate. Plenty of extremely attractive tasks are terrible delegation candidates because they fail one of the other three dimensions. That’s the trap this dimension sets, and the next three are how you avoid it.

Dimension 2 - Agent feasibility

The question: Can an agent realistically do it?

Forget for a moment whether it’s worth it or safe – can the technology, as it exists today, actually perform this task to an acceptable standard?

Sub-questions that let you score it:

A high score looks like: a clearly-describable task, with all necessary context and tools available, bounded in scope, where the current generation of models genuinely performs well.

A low score looks like: a fuzzy, open-ended task that depends on context the agent can’t reach, or requires a level of reliability the technology can’t yet deliver.

The crucial thing about feasibility is that it is the most time-dependent of the four dimensions. A task that scores low today can score high in six months – not because you did anything, but because models improved, tools matured, or the context finally got connected. We’ll come back to this when we talk about “not yet.”

Dimension 3 - Verifiability

The question: Can we tell whether it did it correctly?

People consistently underrate this one – and it’s often what turns an obvious “yes” into a cautious “not yet.”

Verifiability is about observability of correctness. After the agent finishes, how do you know whether the result is good? And more pointedly: how expensive is it to find that out?

Sub-questions that let you score it:

A high score looks like: a task with a clear notion of correctness, where checking is cheap or automatable, and where mistakes announce themselves loudly.

A low score looks like: a task where correctness is subjective or hidden, where verification is as much work as the task itself, and where a wrong result looks indistinguishable from a right one.

Here’s why verifiability is such a powerful gate: an agent you can’t check is an agent you have to trust blindly. Blind trust is fine when the stakes are low and fine when the model is perfect – and it’s a disaster in every case in between. If you can’t verify, you’re not really delegating; you’re gambling.

Dimension 4 - Risk & responsibility

The question: Can we safely allow it to do this?

The final dimension is about consequences and accountability. Even a feasible, verifiable, economically attractive task can be one you shouldn’t hand to an autonomous agent, because of what happens if it goes wrong – or because of who is answerable when it does.

Sub-questions that let you score it (here, high means low risk – safe to delegate):

A high score (meaning low risk) looks like: a task whose mistakes are minor, reversible, and contained, that doesn’t touch sensitive systems, and where no external party is harmed if it’s wrong.

A low score (meaning high risk) looks like: a task that acts irreversibly on the outside world, touches sensitive data or critical systems, or requires a human to remain legally or ethically accountable.

A useful way to think about this dimension: verifiability asks “will I notice the mistake?”, while risk asks “how much does the mistake cost me before I can undo it?” They’re related, but distinct – and a task can pass one while failing the other.

The gating rule

Delegation is not about the average of the four scores.

It’s tempting to add the four scores up, take an average, and delegate anything above some line. That’s exactly the wrong thing to do, because it lets a brilliant score on one dimension paper over a fatal weakness on another. Instead, look at the weakest dimension:

The weakest dimension determines the maximum level of autonomy you can safely grant.

That turns the four scores into a simple scale:

• Very weak on any dimension → Not yet. Don’t delegate this autonomously.
• Medium on the weakest → Delegate with guardrails. Hand it over, but with human review or restricted autonomy.
• Strong across all four → Delegate autonomously.

The average might look great; it doesn’t matter. The weakest link sets the ceiling.

This is what turns four vague feelings into a decision. You’re no longer asking “does this feel like a good AI task?” You’re asking four specific questions, and the weakest answer tells you exactly how much autonomy the task can take.

Not suitable vs. not yet suitable

The gating rule gives you something subtle and valuable: a distinction between “not suitable” and “not yet suitable.”

When a task fails on a dimension, don’t just reject it – ask why, and whether that reason is permanent. Because the four dimensions age very differently:

• A low economic score is usually stable. If the task is rare and trivial, it will probably stay rare and trivial. This is the closest thing to “not suitable, period.”
• A low feasibility score is often temporary. Models get better. Tools mature. The context that wasn’t available gets connected. Today’s “the agent can’t do this” quietly becomes tomorrow’s “actually, now it can.”
• A low verifiability score is frequently fixable by you. Add automated tests. Introduce a structured review step. Build a reconciliation check. You can often engineer verifiability into a task that didn’t have it.
• A low risk score is often fixable by design. Add an approval gate so a human signs off before anything irreversible happens. Restrict what the agent is allowed to execute. Limit its access to sensitive systems. You can frequently shrink the blast radius until the task becomes safe.

So a failing score isn’t a dead end – it’s a diagnosis. It tells you exactly what would have to change before the task becomes agent-ready, which is what makes the framework useful in practice rather than just a way to say no.

NOTE: If the task fails, decompose it and score the individual steps…

Putting it to work

You don’t need a spreadsheet for this, but if you like scoring things properly you can download my scorecard here. In practice, though, the framework works as four questions you run through in your head whenever you’re tempted to hand something to an agent – or tempted to dismiss the idea:

1. Is it worth delegating? (economic attractiveness)
2. Can an agent realistically do it? (feasibility)
3. Can I verify the result? (verifiability)
4. Can I safely allow it? (risk & responsibility)

Then apply the gate. Put the four answers together with the “not yet” thinking, and every task lands in one of three buckets:

1. Delegate now

All four dimensions clear the threshold. The task is worth doing, an agent can do it, you can verify the result, and the risk is acceptable. Hand it over with confidence, and spend your saved time on something an agent can’t do.

2. Delegate with guardrails

The task is attractive and mostly ready, but one or more dimensions need support. This is where most of the interesting real-world tasks live. Let the weak dimension tell you where to put the guardrail. It might mean:

• A human review step, because verifiability is only medium – the agent does the work, a person signs off before it counts.
• Restricted autonomy, because risk is elevated – the agent can propose the action but not execute it, or it can act only within tightly bounded limits.
• An approval gate on the irreversible step, so everything up to the point of no return is automated, and a human makes the final call.

The task still gets delegated. You just don’t grant full autonomy – you grant bounded autonomy, and you use the weak dimension to decide where the boundary goes.

Note: When I say guardrails, I mean enforced guardrails, like permissions, approval gates, access restrictions, validation checks - not merely instructions in a prompt.

3. Not yet

At least one dimension is too weak to make delegation sensible or safe, and you can’t (or won’t) fix it right now. The right move is not to force it. Instead, note which dimension failed and what would have to change, and revisit the task when it does. “Not yet” is a parking space, not a rejection.

Closing thought

The reason I like this framework is that it’s honest about time. The technology is moving fast, and a large share of today’s “not yet” tasks will quietly turn into “delegate now” tasks – some because models improve, and some because you improved the task by adding tests, review steps, or approval gates.

So the framework isn’t a one-time verdict. It’s a lens you keep coming back to. Score a task today, act on the score today – and every so often, score it again. The tasks worth delegating are a moving target, and the four questions are how you keep up.

Remember: If the task isn’t suited for delegation, try to decompose it and score the individual steps…

AI isn’t taking your job. But it’s ready to take a growing list of your tasks – and now you have a way to decide exactly which ones.

Enjoy

Freddy

Addendum - a worked example or two

Let’s run a couple of tasks through the framework to see how it feels in practice.

Example A - Summarising a batch of support tickets into weekly themes.

• Economic: High. It’s done every week, it’s tedious, and it currently eats a chunk of a team lead’s time. ✔
• Feasibility: High. The tickets are text, they’re accessible, and models are very good at this. ✔
• Verifiability: Medium-high. The summary is easy to skim against the source, and mistakes tend to be visible. ✔
• Risk: Low. The output is an internal document nobody acts on blindly, and it’s trivially reversible. ✔

All four clear the bar → Delegate now.

Example B - Drafting and sending replies to customer emails.

• Economic: High. High volume, real time saved. ✔
• Feasibility: High. Drafting a reply is well within reach. ✔
• Verifiability: Medium. A wrong-but-plausible reply can look perfectly fine. ⚠
• Risk: Low if it drafts, high if it sends – an irreversible action reaching a real customer. ✖ (for full autonomy)

The economic and feasibility scores are excellent, but risk on the send step vetoes full autonomy. The fix is obvious once you see it: split the task. Let the agent draft; let a human approve the send. → Delegate with guardrails.

Example C - Reconciling month-end financial figures that feed a regulatory filing.

• Economic: High. ✔
• Feasibility: Possibly high. ✔
• Verifiability: Depends – if there’s a hard reconciliation check, high; if not, dangerously low. ⚠
• Risk: High. Regulatory accountability means a human must remain answerable, and errors are costly and hard to reverse. ✖

Even with strong economics and feasibility, the risk dimension gates it. You might get to “delegate with guardrails” by having the agent prepare and a qualified human own and sign, but never to fully autonomous. → Delegate with guardrails, at most.

Notice how in all three cases, the weakest dimension – not the average – decided the outcome and the shape of the guardrails.

I’ve been thinking about this as a kind of stairway - a set of steps, where each step builds on the one below it. You don’t throw away the previous step when you climb to the next one, you build on top of it. And the further up you go, the more you move from doing the work yourself to designing the system that does the work for you.

So let me try to walk up the stairway with you, step by step. For each step I’ll try to describe what it is, what you are doing and what the AI is doing - and then compare it to the step below.

Step 1 - Old school engineering

This is where we all come from. You sit down, you understand the problem, and you write the code. You design the architecture, you pick the patterns, you name the variables, you handle the edge cases, you write the tests and you fix the bugs.

• What you do: Everything. You are the one turning an idea into working software, one keystroke at a time.
• What the AI does: Nothing - or at most it gives you autocomplete and a squiggly line when you forget a semicolon.

Old school engineering is craftsmanship. It’s slow, it’s deep, and it gives you a complete understanding of every corner of your solution. The downside is obvious - it doesn’t scale with the amount of stuff we want to build today. But make no mistake - this is still the foundation. Everything above this step assumes that somebody, somewhere, understands what good code actually looks like.

Step 2 - Prompt engineering

The first step up the stairway is learning how to ask. Instead of writing the code yourself, you describe what you want and let the AI write it for you. It sounds trivial, but anyone who has tried knows that the quality of what you get back is directly tied to the quality of what you put in.

• What you do: You formulate the request. You choose the words, the constraints, the examples and the tone. You iterate on the prompt until the output is good enough.
• What the AI does: It interprets your prompt and produces a result - code, text, a plan, whatever you asked for.

Compared to old school engineering, you’ve handed over the typing, but you’ve taken on a new skill - the ability to express intent precisely. The trap here is thinking that a clever one-liner prompt is enough. It rarely is, and that’s exactly why the next step exists.

Step 3 - Context engineering

Prompting quickly runs into a wall - the AI simply doesn’t know enough about your world. It doesn’t know your codebase, your conventions, your customers or the decision you made three months ago and never wrote down. Context engineering is the art of feeding the AI the right information at the right time.

• What you do: You decide what the AI needs to know and make sure it gets it - relevant files, documentation, examples, coding guidelines, memory from previous conversations. You curate. You leave out the noise and bring in the signal.
• What the AI does: It reasons over the context you provided and produces a result that actually fits your situation instead of a generic answer.

Where prompt engineering is about the question, context engineering is about the knowledge behind the question. This is where a lot of the real magic happens today - a mediocre prompt with great context beats a great prompt with no context almost every time.

Step 4 - Harness engineering

Once you’ve got prompting and context under control, you realize the AI is much more powerful when it can actually do things - read files, run commands, call APIs, search the web, execute tests. The harness is the machinery around the model - the tools, the guardrails, the permissions and the plumbing that turn a chat box into an agent that can act.

• What you do: You build and configure the environment. You decide which tools the AI has access to, what it’s allowed to do, where the boundaries are and how results flow back in. You design for safety and for capability at the same time.
• What the AI does: It uses the tools you gave it to take actions in the real world, observe the results and adjust.

Compared to context engineering, you’re no longer just feeding information in - you’re giving the AI hands and letting it interact with its environment. This is a big jump, because now the AI can create side effects, and that means the quality of your harness directly determines how much you can trust it to run on its own.

Step 5 - Loop engineering

A single request-and-response is nice, but the really interesting things happen when the AI can work in a loop - try something, check the result, learn from it and try again - until the goal is reached. Loop engineering is about designing that cycle. Plan, act, observe, correct, repeat.

• What you do: You design the feedback loop. You define what “done” looks like, what success and failure mean, how the AI should evaluate its own work and when it should stop. You build the checks and the exit conditions.
• What the AI does: It runs the loop - executing, evaluating, self-correcting and iterating toward the goal, often across many steps, without you in the driver’s seat for every single one.

The difference from harness engineering is autonomy over time. A harness gives the AI hands; a loop gives it persistence. This is where you stop babysitting every action and start trusting the system to grind through a problem on its own - which of course only works if the loop is designed well enough to catch its own mistakes.

Step 6 - Graph engineering

At the top of the stairway, a single agent in a single loop is no longer enough. Real problems have many parts, and the most powerful systems are made up of many agents, tools and loops wired together into a graph - specialists that hand work off to each other, run in parallel, and combine their results. Some people call this workflow or orchestration engineering, but I like the picture of a graph.

• What you do: You design the whole system. You decide what the nodes are, how they connect, who does what, how work flows and where the decisions are made. You architect the collaboration between many moving parts.
• What the AI does: The agents in the graph carry out their specialized roles, coordinate, pass information along the edges and collectively solve a problem far bigger than any single one of them could handle alone.

Compared to loop engineering, you’ve gone from designing one loop to designing an entire organization of loops. You’ve moved almost completely out of the code and into the architecture. Interestingly, this feels a lot like old school system design again - you’re back to thinking about components, boundaries and responsibilities, except now the components are intelligent.

Are there more steps?

Almost certainly. This stairway isn’t finished, and I don’t think it ever will be. People are already talking about evaluation engineering (how do you systematically measure whether any of this actually works?), memory engineering (how do systems remember and learn across time?) and environment engineering (how do you build the sandbox the agents live in?). New steps will keep appearing as fast as we can name them.

And if you look closely, you’ll notice something funny about the whole stairway - the higher you climb, the more it starts to look like classic engineering again. At the top you’re doing architecture, system design and orchestration - just with a very different kind of building block. The fundamentals never went away. They just changed clothes.

But what about vibe coding?

You might be wondering where “vibe coding” fits on this stairway. And the honest answer is - it doesn’t really get its own step. Vibe coding is what happens when you climb onto the prompt step, let go of the handrail and stop looking down. You describe what you want, you accept whatever the AI hands back, you run it, and if it feels right you move on - without ever really reading or understanding the code underneath.

And this is where I can’t help thinking about the old fairy tale from H.C. Andersen about the Emperor’s New Clothes.

You remember the story. Two swindlers promise the emperor the finest suit imaginable - a fabric so special that it is invisible to anyone who is stupid or unfit for their job. Of course there is no fabric at all, but nobody dares to say so. The ministers admire it, the emperor parades through town in it, and the whole crowd cheers at the magnificent clothes - because nobody wants to be the one who can’t see what everybody else is pretending to see. It takes a small child to shout out that the emperor isn’t wearing anything at all.

Vibe coding can feel a lot like that parade. The demo runs, the screen looks great, everybody nods and says how amazing it is - and for a while nobody wants to be the one asking “but has anyone actually looked at the code?” It all works beautifully right up until a little child - or a security review, or a production incident, or the customer’s data - points out that there was never really anything holding it together.

Now, I’m not saying vibe coding is useless. Far from it. For a prototype, a demo or a throwaway experiment it is fantastic, and it can get you to “wow” faster than anything we’ve ever had. The danger is only when we forget that we’re vibing - when we let the cheering crowd convince us that the emperor is fully dressed and ship it straight to production. The bottom step of the stairway, actually knowing what good code looks like, is the child in the crowd. Keep that voice around, and vibe coding becomes a superpower instead of a very well-attended parade.

Vibe coding with guardrails

Here’s the interesting part though - the industry noticed the missing handrail too, and a whole category of tools has appeared to put it back. Tools like Lovable, Bolt, v0, Replit and others let you vibe your way to a working application - but with guardrails baked into the experience.

What makes these tools so fascinating is that they don’t just spit out code and leave you to figure out the rest. They wrap the whole thing in structure. They scaffold a sensible project, wire up a database, handle authentication, deploy it somewhere, keep the pieces consistent and gently steer you away from the worst mistakes. With Lovable in particular, it almost feels like you have an architect sitting next to you while you build - one who quietly takes care of the plumbing, the conventions and the structure, so you can stay focused on describing what you actually want.

Vibe-coding platforms like this are a little like the flying trunk in Hans Christian Andersen’s tale. You climb in, say where you want to go, and suddenly you can travel farther and faster than your own abilities would normally allow. The magic is real — the trunk really does fly. But you didn’t build it, and you don’t entirely know how it works. As long as the trunk keeps flying, that hardly matters. The interesting question comes when it doesn’t.

In stairway terms, this is clever - these tools take the prompt step, and instead of removing the handrail, they build the handrail into the product. The context, the harness and quite a bit of the loop are all handled for you, under the hood, by the tool itself. You get the speed and the joy of vibe coding, but a lot of the engineering rigor that vibe coding usually throws away is quietly being done on your behalf.

In fact, it almost feels less like a stairway and more like an escalator. You step on at the bottom, and the tool carries you up past prompt, context, harness and loop without you having to climb each step yourself. It’s a wonderful ride - just remember that an escalator only goes where it was built to go, and if it ever breaks down, the only way to keep climbing is to know how to walk the steps on your own.

It’s a genuinely powerful place to be. You can go from an idea to a running, deployed app in an afternoon, and the result is far more solid than what raw vibe coding would give you. But I’d still add one small note of caution - the architect is real, but it’s an architect you can’t see. The guardrails are there, but they were designed by someone else, for the general case, not for your specific problem. That’s absolutely fine for a huge number of applications - just remember that when the day comes where you need to understand exactly what your system does and why, the bottom step of the stairway is still waiting for you.

What about Business Central?

This is where it gets personal for me, because I can’t talk about a stairway like this without looking at the world I come from - Business Central.

If I’m completely honest, our current toolset is struggling to keep up with the pace of this stairway. The rest of the industry is stepping onto escalators - vibing full applications into existence, with context, harness and loop handled for them - while we in the AL world are still doing a lot of the climbing by hand. The tooling, the AI support, the context that models have about AL and Business Central, the harnesses and the agents - all of it is trailing behind what developers on mainstream stacks now take for granted. That gap is real, and it isn’t shrinking on its own.

So we need to get our act together. We need to collaborate - across partners, across Microsoft, across the community - to build the context, the tooling and the agents that bring AL and Business Central up onto the same steps everybody else is climbing. If we each try to solve this alone, in our own little corner, it’s not innovation, it’s waste.

Please Note: I will do my utmost to ensure that we have sessions covering all of these aspects at Directions EMEA 2026 in Paris!

Where are you on the stairway?

So here’s my question to you, and I genuinely want to know.

Where are you on the engineering stairway to heaven?

• Are you still happily writing every line yourself, and proud of it?
• Have you learned to prompt, but not yet cracked context?
• Are you feeding your agents rich context and building harnesses around them?
• Are you designing loops and letting things run on their own?
• Or are you already wiring up graphs of agents and orchestrating the whole show?

There’s no shame in being on any particular step - we’re all climbing at our own pace, and honestly nobody has reached the top, because there isn’t one. What matters is that you keep climbing, and that you never forget that the bottom step - actually knowing what good software looks like - is what holds the whole staircase up.

Drop a comment and let me know which step you’re standing on. I’m curious to see where this community is.

Enjoy

/Freddy

A web client? Really?

At first glance it might seem a bit weird that Fkh has a web client at all. Most of the work happens in VS Code, some of it in the CLI - so why on earth would you need a web app on top of that?

The answer is that it is actually pretty handy. When the web client is installed and running on your phone, you can perform some tasks in Fkh right from your phone - without opening a laptop, without a terminal, without VS Code.

At Bunker Holding, every feature developed must be code reviewed and tested in a test environment. The process that for every Pull Request created, you can ask for a review from a consultant, which will trigger the generation of a test environment, which is using AAD authentication. No sharing passwords, no need to submit passwords, secure by design. These PR environments are also shut down at 18:00 every evening and the consultant doesn’t have VS Code and should certainly not need to install the Fkh CLI, so… a Web Client was born.

Why it is so simple

Just like every other interface to Fkh, the web client is only an interface. As I explained in The Fkh CLI, all the functionality lives in the backend, and every interface talks to that same backend.

That has two very concrete consequences for the web client:

• The authentication model is GitHub - the exact same GitHub authentication and group membership that the VS Code extension and the CLI use. There is nothing new to learn, no separate account, no extra secrets.
• All functionality is in the backend - the web client doesn’t implement any logic of its own, it just calls the backend and displays the result.

Because of this, the web client really is very simple. It doesn’t need to be clever - it authenticates you with GitHub, calls the backend, and the backend does all the authentication, authorization and validation exactly as it does for every other interface.

What can you do today?

You find the URL to the Web Client when you deploy Fkh:

Right now, the web client is intentionally focused. You can:

• Start and stop individual containers
• Start and stop the entire Fkh cluster

That covers the scenarios where a phone is genuinely the most convenient tool - the quick “start this before my demo” or “stop everything, I’m done for the day” kind of tasks.

A few screenshots from my phone

3 containers, 2 stopped, one running with the option to stop it.

You can shut down the entire Fkh cluster to save money:

When the Fkh cluster is shut down, you can start it from your phone:

Who knows what the future holds

The web client is deliberately small today, but that doesn’t mean it stays that way. Because it is just another face on the same backend, adding functionality is mostly a matter of surfacing existing backend operations.

So today it is starting and stopping containers and the entire Fkh cluster - but who knows what is needed in the future. If partners and customers using Fkh find that they need more from their phone, it is easy to add.

Wrapping up

The web client is a small but handy addition to the Fkh family. It rides on the same principles as everything else in Fkh - GitHub for authentication, GitHub team membership for authorization, and one backend that does all the work. That is exactly what makes it so simple.

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

Why you don’t have direct access to the container

Just like the SQL Server we looked at in the just-in-time database access post, your Business Central containers run as pods inside the Kubernetes cluster in your own Azure subscription. They are not exposed to the public internet, and there is (by default) no permanent open door from the outside into a container.

This is by design. The containers talk to each other and to the SQL Server from within the cluster, but from the outside there are no standing credentials and no public endpoint to reach in through, and while you could specify 5986 in the ports to open to your container, it could come with a risk.

Note: Fkh containers are set up with a Windows account lockout policy, meaning that if you decide to open the container to the internet, three failed attempts within a 15-minute timeframe would lock the account for 15 minutes, making brute-force attacks unlikely, but can make your containers useless. For shortlived containers in pipelines, this might be an acceptable trade-off.

Most of the time you don’t need terminal access. You create containers, publish apps and work with them straight from VS Code, the Web App or the CLI. But sometimes you genuinely need a shell inside the container - to inspect something, run some PowerShell interactively, or troubleshoot an issue that only shows up on the container itself.

We already saw how Fkh can create a just-in-time tunnel to the SQL Server. Getting into a container follows the same philosophy, and there are really two good ways to do it.

Option 1: Open a terminal with fkh CLI and kubectl (for this you need access to the Azure Portal and Kubernetes)

If you have kubectl installed and you have access to the cluster, the most direct way to get into a container is to use kubectl exec. Since the containers are Windows containers, you open a PowerShell session inside the pod:

fkh open --name <containername>

fkh will check whether you have kubectl installed and if you have - it will check that you are authenticated to the right subscription and that you do have access. If you do not have access (as many people wont), you will be redirected to the poormansterminal, which basically allows you to type in commands and have them executed in the container.

Note: you can add –poormansterminal to the fkh open to force the poor mans terminal, but you still need the fkh CLI installed.

As this mechanism requires you to install the fkh CLI, kubectl and it requires you to have backend access, it is only for admins or infrastructure people.

Option 2: Open a WinRM session with allowwinrmaccess using fkh CLI

The second way is the one that fits the Fkh model best, and it mirrors exactly how just-in-time database access works. Instead of exposing SQL over a temporary tunnel, Fkh opens a temporary, tightly-scoped door for WinRM from your IP address to the container.

Just like there is an Allow Sql Access command, there is an Allow WinRm Access command. When you invoke it, Fkh will:

• Verify who you are using GitHub authentication and check your group membership for authorization.
• Open a temporary door for WinRM scoped to your public IP address only.
• Grant the access for a limited period of time, after which the door is closed again automatically.

Once the command has run, the output tells you the IP address to connect to. From there you create a PowerShell remoting session to the container and work with it as if it were local:

$option = New-PSSessionOption -SkipCACheck -SkipCNCheck
$session = New-PSSession -ConnectionUri https://172.160.98.242:5986/wsman -Credential (Get-Credential) -Authentication Basic -SessionOption $option
Enter-PSSession $session

Inside that session you have a full PowerShell prompt in the container, and you can invoke code, run scripts or copy files across the session using Copy-Item -ToSession. When you are done - or when the time window expires - the door is closed and the access is gone.

Note: just like with SQL access, you can run the corresponding Revoke WinRm Access command if you want to close the door before the timeout.

Option 3: Open a WinRM session with allowwinrmaccess using VS Code

The third way is actually the same as #2 - just from VS Code. If you right click the container on which you want a terminal, you can select Allow WinRm Access and Fkh will open the tunnel for you.

In the output window, you will see something like:

[AllowWinRmAccess] User: <github-user>
Container: <container-name>
Allowed IP: 203.0.113.19/32
WinRM Endpoint: 203.0.113.97:5986
Auto Revoke: 2026-08-10 07:23 UTC (2h)
Connect: Enter-PSSession -ConnectionUri https://4.166.125.97:5986/wsman -Credential (Get-Credential) -Authentication Basic -SessionOption (New-PSSessionOption -SkipCACheck -SkipCNCheck)

Note: that the IP number displayed here is NOT the IP number of the container, it is the IP number of the load balancer in front of the container, which has a tunnel open to the container.

When you now grab the line after connect and run that in the terminal, you will see something like:

Now, your VS Code terminal is inside the container.

Which one should you use?

All options get you a terminal in the container, so it really comes down to how you like to work:

• kubectl is great if you already live in Kubernetes tooling and have kubectl configured. It is direct and needs nothing really from Fkh - but it also assumes you have cluster access set up.
• Allow WinRm Access is the Fkh-native option. It needs no cluster tooling on your machine, it is authenticated and authorized through GitHub, scoped to your IP, and time-limited - exactly like just-in-time database access.

For most people I would recommend the WinRM approach, simply because it gives you the same secure, just-in-time, no-standing-credentials experience as the rest of Fkh, without having to install and configure kubectl and secondly because it also runs in VS Code and can be performed without the fkh CLI installed.

Why this is a good thing

The terminal access model gives you the best of both worlds, just like the database access did:

• Security - the containers are never exposed to the public internet, there are no standing credentials, and every access is authenticated, authorized, scoped to your IP and time-limited.
• Convenience - when you genuinely need a shell in a container, you can have one, using tools you already have, without anyone handing out permanent access.

This is the same philosophy that runs through all of Fkh: no humanly created secrets, managed identities and federated credentials for machine-to-machine access, and GitHub authentication plus group membership for people.

What’s next?

In the coming posts I will continue going into more detail about how to set up Fkh and the functionality that is implemented or planned. One of my ideas is to support test runs directly from fkh, which could even take a snapshot of the database and restore the database afterwords if need be. This would cause the test run to happen in fkh, and your pipelines can do other things while running and only at the very end, wait until all tests are completed. Let me know whether you like that idea?

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

Since Fkh runs entirely in your own Azure subscription, the honest answer is “it depends on your usage” - but that isn’t very helpful, so this post breaks down exactly what has a cost attached, how each part scales as usage grows, and what a realistic monthly bill looks like for 5, 10 and 20 concurrently running containers.

Disclaimer: all numbers in this post are approximate, based on pay-as-you-go pricing and will vary by region, currency, discounts and actual usage. Always use the Azure Pricing Calculator for your own scenario. Prices are in USD.

What has a cost attached?

Fkh is deployed with Terraform, and the resources fall into four buckets: things that are always billed, things that are usage-based (near zero at idle), things that are only billed when you enable them, and things that are free.

Always-billed components

Usage-based / near-zero at idle

Conditional (only billed when enabled)

Free / no direct charge

Managed identities, the resource group, role assignments, Kubernetes secrets/services/network policies, random passwords, and the image pre-pull DaemonSet (it consumes node resources you already pay for, but there is no separate charge).

GitHub repository (builds the Docker images)

Fkh integrates with AL-Go for GitHub, and the generic and specific Business Central Docker images are built by GitHub Actions in your repository. That means your only “cost” here is GitHub Actions minutes - free for public repositories and included (up to your plan’s quota) for private ones. There is no Azure charge for the build itself; the resulting images simply land in your ACR.

Biggest cost drivers: the AKS node pool VMs (Linux always-on + Windows on demand), the 128Gi Premium SSD disk, the per-container Load Balancer rules/public IPs, and Log Analytics ingestion.

How each part scales

The whole point of the design is that a large chunk of the cost is a fixed baseline that is shared by everyone, while the part that grows with usage is mostly Windows compute - and that part scales to zero when nobody is working.

Windows node pool — the big one

This is where your money goes when developers are actually working. Each Business Central container needs CPU and memory, and the Windows node pool autoscales (0–10 by default) to fit the containers that are currently running.

The important characteristics:

• It scales to zero. When no containers are running - nights, weekends, holidays - the Windows node pool has no nodes and therefore no compute cost. You only pay while containers are up.
• It scales with the number of running containers, not headcount. A single developer might have zero, one, or several containers up at once. What matters is how many containers are running at the same time, and for how long - not how many people are on the team. You can define the max. number of containers allowed for each developer.
• Packing matters. A Business Central container needs roughly 3 GB (depending on the size of your apps - you can monitor this and define the requirement on a per project basis), so a Standard_D4s_v5 (4 vCPU / 16 GB) comfortably hosts about 3 containers. More concurrent containers means more nodes - or bigger nodes (see the next section).
• Spot can cut it dramatically. Enabling the Windows Spot node pool (windows_spot_enabled) uses evictable spot capacity at a large discount - great for short-lived, throw-away containers that can tolerate an occasional eviction.

Choosing the right Windows node size

The default Standard_D4s_v5 is a good starting point, but it is not your only option - and the size you choose affects both cost efficiency and how smoothly the pool scales. Because a container needs ~3 GB, the practical density per node looks roughly like this:

Notice that the bigger SKUs pack proportionally more containers - a D16s_v5 costs roughly 4× a D4s_v5 but hosts nearly 7× the containers, because the fixed OS/system overhead per node is amortized over more workloads. So the cost per running container actually drops as the node gets bigger, as long as you keep the node reasonably full.

The trade-off is scaling granularity:

• Small nodes (D4s_v5) scale in fine steps - great for spiky, low-concurrency usage where you want to add and remove capacity three containers at a time and scale to zero quickly. The downside is more wasted headroom when a node is only partly full.
• Large nodes (D8s_v5 / D16s_v5) give the best density and the lowest per-container cost for steady, higher-concurrency workloads, but each scale-up adds a big chunk of capacity at once, so a nearly-idle large node wastes more money than a small one.

Rule of thumb: pick the smallest node that your typical concurrent container count keeps comfortably full. A team that usually runs ~8 containers at a time is better served by one D8s_v5 than three D4s_v5 nodes; a team spiking to ~20 containers is a natural fit for a D16s_v5.

Linux node + SQL disk — mostly fixed

The Linux node runs SQL Server and the system pods 24/7, so it is a fixed cost regardless of how many containers you run. The 128Gi Premium SSD is likewise a fixed, provisioned cost - but it grows if you store more or larger databases. If you upload many database backups or host large databases, you may bump the disk size (or add disks), which increases this line.

Log Analytics — grows gently with usage

Log Analytics is billed per GB ingested. More running containers and more activity means more telemetry, so this line grows slowly as usage increases. It rarely dominates the bill, but it is worth keeping an eye on retention (30 days by default) and what you choose to collect. Container Insights in particular can be tuned down if you don’t need the full firehose.

ACR — flat until you outgrow Basic

On the Basic SKU, ACR is a small, near-flat cost. It grows only if you store a lot of images or need more throughput/geo-replication, at which point you’d move to Standard or Premium. For most teams, Basic is plenty.

Backup storage — grows with what you keep

The DB backup storage is standard blob storage, so it grows linearly with the number and size of the database backups you upload and keep. Pruning old versions (see the file/database storage commands) keeps this in check.

Function App — effectively free

The backend runs on a Y1 Consumption plan, so it is pay-per-execution with no idle cost. Even with a lot of activity and commands, the number of executions is tiny in Azure Functions terms, so this stays negligible.

Load balancer — a per-container cost

Each Business Central container gets its own Kubernetes Service of type LoadBalancer, exposing five ports (80, 443, 7047, 7048, 7049) and its own public IP. On a Standard Load Balancer that is five load-balancing rules and one public IP per container.

Standard Load Balancer pricing (West Europe, Aug 2026) is roughly:

• The first 5 rules are included for free (per hour, across the whole load balancer).
• Each additional rule is ~$0.01 / rule-hour.
• Each public IP is ~$0.006 / IP-hour.

Because the very first container already uses up the 5 free rules, every container after the first is billed for its 5 rules plus its public IP - about 5 × $0.01 + $0.006 ≈ $0.056/hour ≈ ~$41/month per container if it runs 24/7. Unlike compute, this cost is identical whatever node SKU you use - it scales with the number of running containers, not node size. The estimates below include this load balancer cost.

Idea: I an considering adding a feature to containers, where I can disable endpoints to save a buck or two on the load balancer. Let me know if you think that is a good idea. I could also create a traefik-like frontend to get rid of the load balancer all-tigether.

Approximate monthly cost for 5, 10, 20 and 40 running containers

Putting it together, the bill is essentially a shared fixed baseline plus Windows compute that scales with the number of concurrently running containers plus a little extra telemetry.

The numbers below assume a realistic working pattern: each container runs during a working day (~8 hours × ~22 workdays ≈ 176 hours/month) and the Windows node pool scales to zero the rest of the time, ~3 containers per Standard_D4s_v5 node, aks_sku_tier = Free, and no spot node pool. “Running containers” means the peak concurrent number of containers. The totals include the per-container load balancer cost described above. Your mileage will vary.

Shared baseline (independent of container count): ≈ $210/mo

Total estimate (8-hour working day) - approximate total /mo depending on which Windows node SKU you pick (baseline + telemetry + Windows compute + per-container load balancer), with the node pool scaling to zero outside working hours. Each cell shows total /mo ($ per-container /mo) ×node count:

The pattern is clear: for low concurrency the smaller SKUs are cheapest (a D4s_v5 or two), while for high concurrency the bigger SKUs win because they pack containers more densely and carry less per-node overhead. At 40 containers a single D32s_v5 costs about a third less than fourteen D4s_v5 nodes.

Note: the default Windows node pool autoscales 0–10. The 14-node D4s_v5 case for 40 containers would need max_count raised - another reason to reach for a bigger SKU at that scale.

Note also: you can define default (or forced) shutdown time for containers and allow individual developers to extend or restart containers when working overtime (happens sometimes).

But what if you never shut down? (24/7)

Here is the exact same scenario, but assuming you never shut anything down - the containers and their Windows nodes run 24/7 (~730 hours/month), and the per-container load balancers stay allocated around the clock. The baseline is unchanged (the Linux node and the Premium SSD are 24/7 either way), but the Windows compute and the load balancer - and therefore the per-container cost - go up substantially:

Comparing the two tables shows just how much of the bill is under your control: at 40 containers on a D16s_v5, leaving everything running 24/7 instead of an 8-hour working day pushes the total from ~$1,195 up to ~$4,185 - you are now paying for nodes and public IPs around the clock, even when nobody is using them.

Note: there is a new feature coming out, where you can force the entire cluster to shut down during nights and public holidays to save cost.

Two things stand out:

• The per-container cost drops as you grow, because the fixed baseline is shared across all running containers, and larger nodes pack more densely. At 40 containers on a D32s_v5 you are down to roughly $105 per container, versus ~$192 at 5 containers.
• Windows compute dominates the variable cost, which is exactly the part you control - running fewer nodes, good packing, right-sizing the node SKU, scaling to zero out of hours, and enabling spot for evictable workloads can all bring the Windows compute line down substantially.

This makes scaling to zero and StopFkh even more valuable: they don’t just save compute, they release the per-container load balancer rules and public IPs too.

What about a bigger Linux node for SQL?

The baseline above assumes the default single Standard_D4s_v5 Linux node running SQL Server. That is fine for light-to-moderate database usage, but SQL is the one part of the baseline you may genuinely need to scale up - not because of the number of containers, but because of database size, query load, and how many databases are active at once.

If SQL becomes the bottleneck, you would move the Linux node to a larger SKU, and this changes the fixed part of the bill (it is on 24/7):

A few things to keep in mind:

• This is a 24/7 cost, unlike the Windows nodes it does not scale to zero - so upsizing SQL raises your floor every month.
• SQL loves memory. If you are hosting many or large databases, a memory-optimized E-series node (e.g. E8s_v5 with 64 GB) often gives more headroom per dollar than a same-priced general-purpose node.
• The Premium SSD grows separately. More/larger databases usually means bumping the 128Gi Premium SSD too, which adds to the baseline independently of the node size.

For most teams the default D4s_v5 Linux node is plenty and you should only upsize it when you actually observe SQL pressure.

Keeping the bill down

A few levers you have:

• Scale the Windows node pool to zero out of hours. The Windows node pool can drop to zero nodes when no containers are running - nights, weekends, holidays - so you only pay for Windows compute while it is actually up. Compared to the 24/7 table above, scaling to zero outside working hours can easily cut the Windows compute line by more than half - and releases the per-container load balancer rules and public IPs too.
• Shut down the whole cluster with StopFkh. During non-work hours you can stop the entire cluster with StopFkh - both the Linux and Windows node pools - removing almost all the compute cost and the load balancer cost. The one thing that keeps costing money is the persisted Premium SSD disk, which stays allocated (and billed) whether the cluster is running or not.
• Right-size the Windows node SKU. Match the node size to your typical concurrent container count so nodes stay full (see Choosing the right Windows node size).
• Use spot nodes for throw-away containers. Enable windows_spot_enabled for ephemeral, evictable workloads and let them ride the discount.
• Stay on the Free AKS tier unless you need the control-plane SLA (Standard adds ~$73/mo).
• Prune old database backups and file versions to keep blob storage lean.
• Tune Log Analytics retention and collection if telemetry ingestion grows.
• Turn on Kubecost (kubecost_enabled) if you want per-namespace/per-container cost visibility - just remember it consumes a bit of node CPU/memory itself.

What if Business Central would run on Linux?

Everything above assumes Business Central containers run on Windows nodes - and today they do. But a big part of the Windows compute cost is simply the Windows licensing baked into the VM price. A Linux VM of the same size is roughly half the hourly cost of its Windows counterpart, the Linux OS also uses less CPU and memory and Linux is more performant, meaning that we can pack more containers on the same compute. The day Business Central containers can run on Linux, the compute side of this whole post changes fundamentally.

There is a catch during the transition, though. If you have older (Windows) containers running at the same time as new (Linux) containers, you will temporarily be paying for two container node pools instead of one - the existing Windows pool and a new Linux pool for the BC-on-Linux containers. During that overlap your bill actually goes up a little, because you are carrying both.

But that is a temporary situation. As you retire the older Windows-based containers and everything moves onto Linux, you drop the expensive Windows node pool entirely, and the container compute lands on Linux nodes at roughly half the price. The end result is that pricing drops pretty dramatically - the single biggest variable cost in Fkh gets cut roughly in half, on top of all the levers (scale-to-zero, StopFkh, right-sizing) you already have.

So the honest picture is: a short-term bump while you run old and new side by side, followed by a significant, lasting reduction once you are fully on Linux.

Comparing with other services

Azure Container Instances

When running Azure Container Instances with the standard Microsoft Business Central images, you cannot really stop and start containers - stopping a container removes the database as well, and starting a new ACI takes a very long time. In terms of pricing, an ACI with 2 vCPUs and 12 GB of memory is around $160 per month, and there is no real infrastructure around it - no integration with AL-Go or anything - so it wastes a lot of hours where your developers could be doing real work. With the current functionality in ACIs, I do not see them as relevant for Business Central work.

Azure VMs

When running Azure VMs, you could use Traefik and pack more containers onto one VM, but this also requires serious infrastructure - or it wastes time for your developers and requires them to have permissions and budget in the Azure Portal. Pricing for an Azure VM is in the same ballpark as ACIs, but with more overhead on installation and maintenance.

Idea: I could build support in Fkh for using Azure VMs as an alternative to a K8s cluster, and then allowing Fkh to set up VMs and pack containers on these instead. This might make Fkh more useful for smaller partners as well, and it would be seamless for the developer.

Cosmo Alpaca

For Cosmo Alpaca, you pay per container per minute, meaning that you have a much easier price calculation. Cheapest price I saw on their website is around $1 per hour (I think you can get a cheaper price when using a lot of compute), which would sum up to around $176 per month per container, but here you have a fully integrated VS Code extension, which helps you work with containers, saving time for your developers to do real work.

Locally running containers

Locally running containers obviously doesn’t incur any Azure costs, but they do take time away from your developers and this can be a significant amount of hours wasted.

Why I don’t host Fkh for partners and customers

There are many reasons, but the primary two are these:

If I were to host Fkh, I would essentially be running the Linux SQL Server in Production and would have to pay license costs to Microsoft for hosting a SQL Server for my customers (not cheap) - even though they use it for Development and Test.

Partners and customers would be tied to me as a vendor with nowhere else to go (without a moving cost). I don’t want to put partners and customers in this situation and I don’t think they would want to put themselves in that situation either.

Wrapping up

Fkh is not free to run - it uses real Azure resources in your own subscription - but the design keeps the fixed cost small and pushes the variable cost onto Windows compute that you control. The tables above assume the node pool runs 24/7, but scaling the Windows node pool to zero out of hours - or stopping the whole cluster with StopFkh and paying only for the persisted disk - can remove more than half of that compute. The result is a bill that scales gracefully and gets cheaper per running container as your usage grows.

Realistically, in a company with 20 developers, you will be running containers at ~$42 per month (≈ $0.004 per minute) when set up correctly. But pricing isn’t really the biggest advantage of Fkh. The biggest advantage is that it is all yours: you are in control, the data never leaves your subscription, the product is open source, the pricing is the Azure cost, it is secure, and your developers don’t need any elevated privileges or permissions, nor do they need access to Azure resources or budget.

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

The Fkh file storage basically gets rid of SAS URLs or secret URLs — you have a trusted file storage that you can access wherever you need it.

Why file storage?

When you work with Business Central containers, there are always files you need to have around - license files, apps, configuration files, scripts, and much more. Rather than passing these around by hand or storing them in some ad-hoc location, Fkh gives you a proper, versioned file storage that lives in blob storage in your own Azure subscription.

Just like everything else in Fkh, you reach the file storage through the same authenticated and authorized channels - there are no standing credentials or public endpoints. Uploading and removing files are admin-only operations, while downloading and listing are available to the users who need them.

The storage is versioned. Every file is stored under a name, and each upload creates a new version under that name. A version manifest (all.json) keeps track of all versions and which one is the latest, so you can always grab the latest version or pin to a specific one.

The Fkh CLI

While most of Fkh is available directly from VS Code, the file storage commands are a great example of where the Fkh CLI shines - especially when you want to script things or use them from a pipeline.

Uploading a file

fkh uploadfile uploads a local file to blob storage and updates the version manifest (all.json) with all versions and the latest. This is an admin-only operation.

The key parameters are:

• --localPath <file> (required) - path to the local file to upload.
• --fileName <string> (required) - the file name, used as the folder name in blob storage.
• --fileVersion <string> (optional) - a version label for this file, used as the blob name. If you don’t specify it, it defaults to the current UTC time as yyyyMMddHHmm.

fkh uploadfile --localPath ".\my.bclicense" --fileName "mylicense" --fileVersion "20260806"

If you leave out --fileVersion, Fkh will simply stamp it with the current UTC time, which is a nice way to keep a rolling history without having to invent version labels yourself.

Note: Files are not sorted by fileVersion — it’s simply a tag, and the most recently uploaded file becomes the latest.

Downloading a file

fkh downloadfile downloads a versioned file from blob storage. You specify the file as blob/version, or just blob to use the latest version.

• --file <string> (required) - the file to download, as blob/version or just blob for the latest.
• --output <string> (optional) - the file path to save the downloaded file to. Defaults to blob-version in the current directory.

# Download the latest version of "mylicense"
fkh downloadfile --file "mylicense" --output ".\my.bclicense"

# Download a specific version
fkh downloadfile --file "mylicense/20260806" --output ".\my.bclicense"

Because you can always ask for just the name and get the latest version, scripts and pipelines can stay blissfully unaware of version labels while still getting the most recent file.

Listing files

fkh listfiles lists the uploaded files in blob storage. You filter with a name/version pattern where both sides support wildcards - * matches any characters and ? matches a single character. The version side also accepts the keyword latest.

• --file <string> (optional, default */latest) - the filter as name/version.

A few examples of what the filter can do:

• */latest (the default) - the latest version of every file.
• */* - all versions of all files.
• name/* - all versions of a single file.
• my*/latest or log??/* - pattern matching on both the name and the version.

# List the latest version of every file (default)
fkh listfiles

# List every version of every file
fkh listfiles --file "*/*"

# List all versions of the "license" file
fkh listfiles --file "mylicense/*"

Combine --asJson with these filters and you have a very scriptable way of inspecting exactly what is in your storage.

Removing a file

fkh removefile removes an uploaded file version from blob storage and updates the version manifest (all.json). Like uploading, this is an admin-only operation.

You specify the file as name/version, or just name to remove the latest version - in which case latest is repointed to the previous version.

• --file <string> (required) - the file to remove, as name/version or just name for the latest.
• --confirm - skip the interactive confirmation prompt (useful in scripts).

# Remove a specific version
fkh removefile --file "mylicense/20260806"

# Remove the latest version (latest repoints to the previous one)
fkh removefile --file "mylicense"

# Skip the confirmation prompt, e.g. from a pipeline
fkh removefile --file "mylicense/20260806" --confirm

The fact that removing the latest version automatically repoints latest to the previous version means you can safely roll back a bad upload without breaking anyone who is asking for the latest version.

And the same for databases

The file storage is only half the story. A very similar set of commands exists for databases - you can upload a database and then use it when creating containers, so that new containers come up with exactly the data you want.

This is a powerful building block: imagine restoring your online Business Central database once, uploading it to Fkh, and then spinning up containers based on that database whenever you need them. But more about this later.

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

One backend, many interfaces

The most important thing to understand about Fkh is that all the functionality lives in the backend. The backend is an Azure Function running in your own Azure subscription - is the single place that authenticates you, authorizes you against your GitHub team memberships, and actually performs the work.

Everything else is just an interface to that backend:

• The VS Code extension is an interface.
• The CLI is an interface.
• The Web app is an interface.

GitHub Actions and Azure DevOps talks to the same interface typically using the CLI authenticating using federated credentials (OIDC).

graph LR
    subgraph Interfaces
        VSIX["VS Code Extension"]
        CLI["Fkh CLI"]
        WEB["Web app"]
        GA["GitHub Actions"]
        ADO["Azure DevOps"]
    end

    FUNC["Fkh Backend<br/>(Azure Function)"]
    FKH["Kubernetes Cluster,<br/>Storage, Logs,..."]
    GH["GitHub<br/>(auth + teams)"]

    VSIX --> FUNC
    CLI --> FUNC
    WEB --> FUNC
    GA --> CLI
    ADO --> CLI
    FUNC --> GH
    FUNC --> FKH

This is a deliberate design choice. Because the backend is the bearer of permissions, the interface you happen to use doesn’t matter for security - whether you create a container from VS Code, from the CLI, or from a pipeline, the exact same authentication, authorization and validation happens on the backend. The CLI cannot do anything the backend won’t allow.

Installing the CLI

The Fkh CLI is available on NuGet as a dotnet tool and is installed by using:

dotnet tool install|update --global fkh [--prerelease]

After installing the CLI, you need to specify backend and GitHub user account, and then you can get the function catalog by writing:

Note: many more functions are available and more functions will be added as needed by partners and customers using Fkh.

Over the coming weeks/months, I will desribe the functionality in Fkh in larger detail.

But, who needs a CLI?

If most people work in VS Code, why do we need a CLI at all?

As the matter of fact, most people probably won’t need to install the Fkh CLI. Admins might want to, but it isn’t a requirement for most things.

But, not everything is interactive. Pipelines, scheduled jobs, build agents and automation scripts don’t open VS Code and click buttons - they run commands. The CLI is built exactly for those scenarios:

• DevOps pipelines - spin up a container to run your tests, publish your apps, then tear it down again.
• Scheduled maintenance - clean up old containers, refresh databases, prune file versions.
• Scripting and glue - combine Fkh operations with everything else you do from a shell.

Because the CLI speaks the same backend as everything else, a container you create from a pipeline is a first-class citizen - you can see it and manage it from VS Code afterwards, and vice versa.

Authenticating from a pipeline

The one thing a pipeline needs is a way to prove who it is - and Fkh uses GitHub for that, just like it does for humans.

The pipeline needs the ID_TOKEN: write permission, which enables OIDC and in GitHub Actions you use OIDC with the --useOIDC option, which fetches a short-lived token from GitHub Actions and auto-refreshes it. There are no secrets to store - no personal access tokens, no passwords, nothing to rotate or leak.

# Inside a GitHub Actions job
fkh listcontainers --useOIDC --asJson

Outside of GitHub Actions - for example on a local machine or a self-hosted agent using the GitHub CLI - you can authenticate with your GitHub account using --ghUser <user> (or the GH_USER environment variable).

The common options you will reach for most often are:

• --useOIDC - authenticate using the GitHub Actions OIDC token (pipelines).
• --ghUser <user> - GitHub user account for the gh auth token (or the GH_USER environment variable).
• --backendUrl <url> - override the backend URL.
• --asJson - output the result as JSON so you can parse it in later steps.
• --nowait - don’t wait for completion, fire and continue.
• -h / --help - show help for any command.

The same commands, everywhere

Most of what you can do in the CLI is also available in VS Code through the Fkh: Run Command command. That gives you a menu of the available operations, and it invokes exactly the same backend operations the CLI does.

So the mental model is simple: there is one set of commands, and you pick the interface that fits the moment.

• Working interactively? Use the VS Code extension, or Fkh: Run Command for the less common operations.
• Automating? Use the CLI with --useOIDC in your pipeline.

You don’t have to learn two different tools with two different capabilities - you learn the commands once, and you use them from wherever makes sense.

Wrapping up

The CLI is a small tool with a big idea behind it: Fkh is one backend, and the CLI is just one of its faces. Everything the CLI can do, the backend does, under the same security model as the VS Code extension - and most of it is available in VS Code too through Fkh: Run Command.

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

Why you don’t have direct database access

As explained in the security model post, the databases for your containers live on a SQL Server (Developer edition) running inside the Kubernetes cluster in your own Azure subscription. The containers connect to that SQL Server over TCP 1433 from within the cluster.

This is by design. The SQL Server is not exposed to the public internet, and you do not have a permanent connection string, username or password on your local machine. There are no standing credentials to leak, rotate, or lose.

But sometimes you genuinely need to get into the database - to inspect data, run a query, troubleshoot an issue, or point SQL Server Management Studio (SSMS) or Azure Data Studio at it. That is where just-in-time database access comes in.

What is just-in-time database access?

Just-in-time (JIT) database access means that instead of having a permanent, always-open door to the database, Fkh opens a temporary, tightly-scoped door only when you need it, and closes it again automatically after a limited period of time.

When you request access, Fkh will:

• Verify who you are using GitHub authentication and check your group membership for authorization.
• If requested, create a temporary database user with your GitHub username and the password you specify.
• Open a temporary network tunnel into the cluster so your local tools can reach the SQL Server.
• Grant the access for a limited period of time, after which the user and the tunnel are removed automatically.

No standing users, no shared passwords, no secrets stored on your machine.

How to get access from your computer

In VS Code you will need the Microsoft SQL Server extension (or another tool) as well as the Fkh extension. To open a tunnel from your machine to the SQL Server, you need to invoke one of the many commands from Fkh:

Locate the Allow Sql Access command and invoke it:

Specify the password you want to use for your temporary user in SQL:

Note: you can also use the Fkh CLI to get access; it works exactly the same way. More about this later.

After successfully running the command, the output window displays the IP address of your SQL Connection. Use this info to create a new connection in the SQL Server extension:

Select the database, create a new query and enjoy access to the database until it is automatically revoked.

Note: you can always run the Revoke Sql Access command if you want to close the network tunnel before timeout.

Request flow for database access

The flow for requesting just-in-time database access follows the same pattern as the rest of Fkh - the backend function is the bearer of permissions, and the user just proves who they are with GitHub:

graph LR
    A["User"] -->|"Request DB access<br/>Bearer: github_token"| B["Backend function<br/>(auth + validate)"]
    B -->|"Check membership"| C["GitHub Teams"]
    B --> D["Create temporary<br/>SQL user + password"]
    B --> E["Open temporary<br/>network tunnel"]
    D --> F["SQL Server<br/>(in AKS)"]
    E --> F
    F -->|"time-limited access"| A
    B -->|"after expiry"| G["Revoke user<br/>+ close tunnel"]

Authorization for database access

As with everything else in Fkh, authorization is based on your GitHub team membership and the highest privilege wins:

• Supporters can see logs and statuses, but do not get database access.
• Members can get just-in-time access to the databases of their own containers.
• Admins can get just-in-time access to any container’s database.

If an authenticated user is not a member of any of the configured groups, they get no access at all.

Connecting with your tools

Once the temporary user, password and tunnel are in place, you can connect with the tools you already know - SQL Server Management Studio (SSMS), Azure Data Studio, sqlcmd, or anything else that speaks TDS - using the connection details Fkh gives you.

Because the access is time-limited, you don’t have to remember to clean anything up. When the window expires, the temporary user is dropped and the tunnel is closed automatically. If you need access again later, you simply request it again.

Why this is a good thing

The just-in-time model gives you the best of both worlds:

• Security - there are no permanent credentials, no public database endpoint, and every access is authenticated, authorized, scoped and time-limited.
• Convenience - when you need to get into the database, you can, using the tools you already have, without begging anyone for a connection string or a password.

This is the same philosophy that runs through all of Fkh: no humanly created secrets, managed identities and federated credentials for machine-to-machine access, and GitHub authentication plus group membership for people.

What’s next?

One of my ideas is to create a one-click restore of my online Business Central into Fkh, having SQL Server Developer edition in the midst removes the restrictions from SQL Express inside the containers, wouldn’t that be cool.

In the coming posts I will go into more detail about the file storage, how to set up Fkh, and the functionality that is implemented or planned.

As always, take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy

It’s all yours

First of all, Fkh is not hosted by me or any other organization. When using Fkh, it is hosted in your own Azure subscription and your data never leaves your subscriptions.

Secondly, Fkh is Open Source, which prevents you from vendor lock-in and if the product doesn’t take the direction you want or you are waiting for functionality you need, you can add this to your own version of Fkh and create a PR.

Lastly, Fkh doesn’t store or require any passwords or any humanly created secrets or personal access tokens. Everything in Fkh uses managed identities, federated credentials, just-in-time access. GitHub authentication is used for you to prove who you are and GitHub group memberships are used to define what you have access to.

GitHub authentication

When configured properly, GitHub authentication is considered secure, and being the leading source code repository for enterprises, I am confident that it will stay like that. Utilizing GitHub authentication for Fkh seemed like the right approach to avoid having to create my own. Also, with the tight integration to AL-Go for GitHub, it was just a no-brainer.

GitHub authorization

With GitHub handling the authentication securely, how do we then handle authorization in a secure way? The solution implemented in Fkh is that the configuration holds the name of 0+ GitHub teams for supporters, members and admins.

Highest privilege wins - if an authenticated user is not a member of any of the configured groups, they have no access. If an authenticated user is a member of one or multiple groups, they will get the highest privilege.

Supporters will be able to see logs and statuses, Members will be able to see and manage own containers, databases etc., Admins will be able to see and manage all containers, databases, storage etc.

Request flow for CreateContainer

When a user is creating a container, whether it being from VS Code, the CLI or any other tool, the flow goes like this:

graph LR
    A["User"] -->|"POST /api/CreateContainer<br/>Bearer: github_token"| B["Backend function<br/>(auth + validate)"]
    B -->|"Check membership"| C["GitHub Teams"]
    B --> D["FkhCreateContainer"]
    D --> E["Check ACR image"]
    D --> F["Restore DB"]
    D --> G["Create K8s resources"]
    E -->|"missing?"| H["Trigger GitHub Actions<br/>(build image)"]

The security model

As shown in the above diagram, the individual users of Fkh doesn’t need access to any Azure resources, nor do they need to be an admin on the computer they are working on. The backend function is the bearer of permissions for handling resources and containers, and users just need to authenticate and provide proof-of-identity using GitHub.

A high level overview of the architecture is here:

graph LR
    subgraph Clients
        VSIX["VS Code Extension"]
        CLI["CLI Tool"]
    end

    GA["GitHub Actions<br/>(CreateImages)"]
    GA2["GitHub Actions"]
    USER["User"]
    FUNC["Fkh Backend<br/>(Azure Function)"]
    GH["GitHub API"]
    GHTEAMS["GitHub<br/>Org Teams"]

    subgraph AKS["AKS Cluster"]
        direction TB
        SQL["SQL Server<br/>(Linux)"]
        BC["BC Containers<br/>(Windows)"]
        SPOT["BC Containers<br/>(Windows Spot)"]
    end

    ACR["Container<br/>Registry"]
    BLOB["Blob Storage<br/>(.bak files)"]
    AAD["Azure AD<br/>Deploy Identity"]

    USER --> VSIX
    USER --> CLI
    USER -->|"team membership"| GHTEAMS
    VSIX -->|"GitHub token"| FUNC
    CLI -->|"GitHub token<br/>or OIDC token"| FUNC
    FUNC -->|"validate user"| GH
    FUNC <-->|"check membership"| GHTEAMS
    FUNC -->|"manage containers"| AKS
    FUNC -->|"check/pull images"| ACR
    FUNC -->|"database backups"| BLOB
    FUNC -->|"dispatch workflow<br/>(GitHub App)"| GA
    BC & SPOT -->|"TCP 1433"| SQL
    GA -->|"OIDC"| AAD
    GA2 -->|"OIDC token"| CLI
    AAD -->|"federated credential"| ACR
    AAD -->|"federated credential"| BLOB

As shown in the diagram, access is possible from users or from GitHub actions using federated credentials. In both cases, you specify who and what have access.

All access from code (GitHub actions) are considered admin access and can manage everything.

Note: the diagram shows that all containers use a SQL Server on Linux instead of the built-in SQL Express inside the container. The reason for this is that containers on Kubernetes cannot be stopped. They scale to 0 and are removed, but the database persists.

SQL Server Developer edition

The SQL Server in the kubernetes cluster is a SQL Server Developer edition, which includes the full feature set (over the SQL Express). Since Fkh is hosted in your own Azure subscription, and only used for development and testing, you are allowed to use this at no license cost.

Note: if I were to host Fkh for other partners and allow them to share a cluster, I would have to pay license costs for the SQL Server as for me, it would be a production setup.

Just-in-time database access

As the databases resides inside the Kubernetes cluster, you do not have database access from your local PC. Fkh does make it possible for users to get just-in-time access to the database for a limited period of time with a temporary network tunnel and user. More about this later.

My containers vs. all containers

In VS Code, you will see a list of your containers in the Fkh window. Admins have the ability to click the small see-all icon, to see and manage all containers. More about this later.

A secure storage account for your pipelines

Fkh also contains a storage account for databases and other files, which can be used for secure file storage with no need for SAS URLs, tokens and secrets - authenticated workflows have access to get what they need. More about this later.

What’s next?

Next posts will be going in more details about the database, the file storage, how to setup Fkh and new functionality implemented or planned.

The current functionality of Fkh is very much the result of one of the customers using Fkh, Bunker Holding Group. My vision and the requirements from Bunker, is what made Fkh what it is today. New functionality in Fkh will very much come from my ideas or from requirements from sponsors and customers.

Stay tuned and feel free to take a look at the project on GitHub: https://github.com/Freddy-DK/Fkh and please consider sponsoring me or setting up a support service agreement to keep this project alive and thriving.

Enjoy

Freddy