The deploy layer for forward-deployed engineers

Build with your agent, ship inside the client's own infrastructure, and leave behind something their team can run — with the audit and SSO their security team already wants. Self-hosted, agent-native, open source. Whether your title is FDE, solutions engineer, implementation engineer, or agency lead, the job is the same: get what you built running in your customer's environment, fast.

Who's building forward-deployed teams

Palantir invented the role; today it's one of the fastest-growing jobs in AI — and the work always lands inside the customer's own environment, where AppCrane runs.

Named as examples of where the role is growing — not AppCrane users.

The job: ship it where the client's data already lives

Forward-deployed work doesn't end at a prototype. You embed with the customer, build the thing with your agent, and it has to run in their environment — their VPC, their on-prem box, sometimes an air-gapped network with no outbound at all. That rules out Vercel, Railway, and Render on day one: the customer's code, data, and IP can't sit on a vendor's cloud, and most deploy SaaS phones home.

So the deploy gets hand-rolled — Docker, ingress, secrets, IAM, a deploy script, and a spreadsheet of who-changed-what — then rebuilt from scratch at the next engagement. AppCrane is that layer, done once and portable: one command on a plain Ubuntu box inside the client's perimeter, and you have Docker-isolated apps, auto-HTTPS, health-gated deploys that revert to the previous image on failure, per-user audit, and SSO — driven by the agent you already work in. It sits on top of your stack; it doesn't replace your judgment about their infra.

# one command inside the client's VPC / on-prem box
curl -fsSL https://raw.githubusercontent.com/gitayg/appCrane/main/install.sh | sudo bash

Agent-native: your agent ships it over MCP

You already build with agents — MCP servers, sub-agents, skills. But you still deploy by hand: kubectl, Terraform, a pile of scripts. AppCrane closes that gap. It exposes 59 appcrane_* tools over the Model Context Protocol, so Claude Code, Cursor, or Codex can create an app, deploy to sandbox, and promote to production in plain language — the same workflow at every client. Real branches, real PRs; your CI and reviews still apply. Walkthrough: Deploy from Claude & Cursor.

Three ways to ship in a client env — and the trade-off

Managed clouds are out the moment the client's data can't leave their perimeter. DIY works but re-solves auth, ingress, audit, and handoff at every engagement. AppCrane is the middle path: the managed-PaaS experience, self-hosted on their box.

The handoff that survives you

Engagements end by transferring ownership — and the failure mode is well documented: you leave, and the client inherits raw Kubernetes and Terraform nobody on their team fully understands. AppCrane is the leave-behind that doesn't rot. It runs on their server with a dashboard, SSO, a role model scoped per app, and a per-user audit trail their team already knows how to operate. No vendor account to transfer, no license to renew — it's open source, and it's theirs.

Open source is the point, not a footnote

FDEs vet tools by reading the source before dropping them into a customer VPC. AppCrane is AGPL-3.0 on GitHub: auditable, self-hostable, with no analytics or telemetry package anywhere in the server and no licensing callback to activate anything. The source is the trust, and the security review reads the code rather than a datasheet. A commercial licence exists separately for running private modifications as a service; it changes the licence terms, not the feature set.

Be honest about restricted egress

A customer network with no outbound is the hardest version of this job, and it is worth saying exactly where AppCrane stands rather than putting a tick in a box. Supply-chain verification can be switched off for an offline box, and container images can be loaded from an archive instead of pulled. But dependency scanning queries OSV, image scanning pulls a pinned Trivy, TLS via ACME needs Let's Encrypt, and GitHub-backed apps need GitHub. On a genuinely air-gapped network you supply the certificate, load images from the archive, and go without scanning — which is workable, and is not the same thing as "runs air-gapped". Test it on the customer's network before you promise it.

Frequently asked

Related