Forward Deployed Engineer

About Linro

Linro is a Berlin-based cloud security company building a real-time, agentic cloud-security platform. Teams ship with AI. AI ships with Linro.

Infrastructure changes constantly, and increasingly it's AI agents making the changes. Tools that scan snapshots and flag risk after the fact can't keep up. Linro enforces intended state across the whole lifecycle instead, from commit to runtime: MCP and pre-commit hooks at commit time, blast-radius simulation that blocks bad changes before they ship, and real-time detection, enforcement and auto-remediation in production. Most tools tell you what's wrong. Linro stops it.

We have each been on the receiving end of this problem: Running cloud security at scale, building the platforms underneath it, and shipping in regulated systems where a wrong change isn't an option. Founded in Berlin in 2026 and built fully remote across Europe, Linro has a platform that's real and working, with plenty still to shape.

The role

Every customer runs their cloud differently: different providers, account structures, network boundaries and change processes. Linro has to run reliably inside all of them. You take a customer from signed agreement to a working install and the first blocked change, then you operate that install: upgrades, health, incidents and tuning. It is SRE work where production is a fleet of customer environments, none of them alike, instead of one platform you control.

Our founders and go-to-market team own the commercial relationship. You own the technical one. Part of this happens on-site, where you may spend a few days at a customer's office to get an install running or work through a problem with their team. This is an engineering role, not a support or sales role, and there is no quota.

What you will do

• Deploy into environments you did not design: connect the customer's cloud organization, set up least-privilege access, deploy sensors (managed, or inside the customer's own cluster) and get to a first blocked change fast.

• Operate the install fleet: define what healthy means for each install, alert on it, and run upgrades and maintenance windows that fit the customer's change process. You know an install is unhealthy before the customer does.

• Lead incidents in customer environments: debug across their network, identity and cluster setup, often with limited access. Fix what you can, hand reproducible findings to engineering, and write postmortems that change something.

• Turn one-off setups into repeatable ones: Terraform modules, Helm values, runbooks and install playbooks, so each new customer takes less effort than the last.

• Wire Linro guardrails into the customer's Terraform and CI/CD workflows, and into their AI coding agents through MCP.

• Write and tune SQL-based policies and policy packs mapped to each customer's frameworks (SOC 2, ISO 27001, NIS2, DORA), and keep false positives low.

• Close the loop: structured feedback to product and engineering, and a seat in scoping calls so that what we promise is what installs.

What we are looking for

• 5+ years operating production cloud infrastructure as an SRE, platform or infrastructure engineer. Part of that in environments you did not own: customer deployments, consulting, or a platform team serving many internal teams.

• Deep, hands-on operation of at least one of AWS, GCP or Azure, and working knowledge of a second. Deep means you have run it, not just deployed to it: organization and account structure, cross-account identity and access, private networking, audit logging, and the failure modes. You can justify every permission you ask a customer for. We go into depth on this in the interviews.

• 3+ years of production Kubernetes with Helm, including debugging OOMs, resource limits and failed rollouts in clusters you do not administer.

• Terraform in multi-account, multi-environment setups, with CI/CD and short-lived credentials.

• Restricted-network experience: proxies, private connectivity, data residency, self-hosted or in-cluster installs.

• Go or Python. You write real code for tooling and integrations, read Go services, and are comfortable with SQL and APIs.

• Observability and incident ownership: symptom-based alerting with Prometheus, Grafana or OpenTelemetry, and experience leading production incidents.

• You can work with customers. You explain trade-offs clearly to engineers and executives, set honest expectations, and understand change management, approvals and audit processes well enough to fit Linro into them. Fluent English.

• You use AI coding agents daily, including for infrastructure changes, have hands-on MCP experience, and know where to trust them and where to check their output.

• Open to travel to customers across Europe and the US, up to roughly a quarter of your time.

Nice to have

• Production experience on more than one of AWS, GCP and Azure.

• Shipping and upgrading software in customer-run environments as a vendor.

• Turning compliance frameworks (SOC 2, ISO 27001, NIS2, DORA) into concrete controls.

• Policy-as-code (OPA/Rego, Sentinel, Cedar) or CSPM tooling.

• Previous forward deployed, solutions engineering or consulting work.

How we work

This role is remote in Germany or Hungary. From time to time you will be in Berlin to work with the founders in person. The rest of the team is remote in Germany, Hungary and other European countries, and we get everyone together in person somewhere in Europe once a quarter for a few days. We work async by default, write things down, and protect people's focus time.

What we offer

• Real ownership. You own every customer deployment and how it runs, with direct access to the founders and to the engineers who built what you are operating.

• Meaningful equity. You are an early employee, and your stake reflects it.

• Competitive salary, benchmarked to the market.

• A quarterly European offsite, and a team that takes both the mission and each other's time seriously.

The honest version

This is early. You will often be the first person to run Linro in a given kind of environment, and no two customers look alike. Runbooks are thin and you will write most of them. You will sometimes debug with less access than you want, on someone else's change calendar. If you want one production environment you fully control, or a polished onboarding process, this is not it. If you like making a security product work in messy real-world setups, and you like the idea of deploying the thing that keeps AI agents from breaking production, we should talk.