Senior Platform Engineer

Copenhagen, on site. Permanent, full time. Senior. Reporting to the CTPO.

Anthill builds the software that pharmaceutical companies use to create, approve and run their digital communication. Our products are used by the commercial and medical teams at some of the world's largest pharmaceutical companies to produce and distribute regulated content. We are around 70 people with our headquarters in Copenhagen and a product suite that includes Activator, Arcane, Amplify and Anthill Cloud, with LLM based capability already running in production.

Anthill is on an ambitious growth path and is an exciting place to work. In our centrally located Copenhagen office, engineers, designers, product people and strategists work side by side. We are an international team with more than 15 nationalities, and English is both the official and the everyday language, in the office and in the code.

Engineering runs on AWS with Terraform, Buildkite and a mono repo for our newest platform.

The role

Our product teams own their own infrastructure. They write their own Terraform, run their own pipelines and deploy themselves, and we intend to keep it that way.

This role owns the platform layer they build on: the AWS account model, identity and access, secrets, agent infrastructure, guardrails, observability, reliability and cost across a multi-account AWS organisation serving regulated customers.

What you own

• The AWS account model: provisioning, service control policies, region policy, tagging and naming conventions across the organisation
• Identity and access across the full lifecycle, creation, review and removal, and the move to single sign-on
• Secrets management: one place secrets live, with automated rotation for service credentials
• Vulnerability management and hardening of the infrastructure itself: baselines, image and runtime currency, segregation and isolation, and the scanning and enforcement point for container and dependency findings
• Agent infrastructure: secure, reliable infrastructure connecting AI agents to internal systems, balancing autonomy with control. You control who can invoke what and that it is logged, not what is asked
• One observability standard across products for logging, alerting, monitoring and tracing, and an alerting model where cost, security and infrastructure alerts have a named owner and a defined action
• Reliability and continuity: backup policy, scheduled restore testing, disaster recovery, infrastructure and container health monitoring, and the escalation path when something breaks
• Cost: visibility per account and service, anomaly response, and the budgets and spending limits that prevent a surprise rather than report one
• Cross-product services outside application code: CI, DNS, certificates and domains. The CI platform decision sits with this role. We run Buildkite today

What good looks like at 90 days

Guardrails defined and enforced across the account estate. Our newest platform running under them. One observability standard live. The access lifecycle automated to the point where offboarding is a single action.

What we are looking for

Deep AWS rather than broad cloud, including Organizations and service control policies. Infrastructure as code in production: Terraform, CloudFormation, Pulumi or similar, we use Terraform. Containers in production, Docker and orchestration on AWS. Real experience with identity and single sign-on, Auth0 in particular if you have it. Infrastructure hardening and vulnerability management as an operational discipline rather than a report you forward. Comfort in Node.js or Bash, because this role automates manual work away rather than absorbing it. Observability tooling such as CloudWatch, Better Stack or Datadog, with enough judgement to standardise on one and defend the choice. CI systems: Buildkite, GitHub Actions, GitLab CI, Jenkins or similar, we use Buildkite. And comfort defining standards that other teams build against.

We also want someone who has thought seriously about agent infrastructure. We are connecting AI agents to internal systems, and the hard problems there are credential scoping, audit and blast radius rather than prompts. If you have opinions about what a non-human identity should and should not be allowed to hold, we want to hear them.

Having supported a compliance or certification effort, ISO 27001 or similar, is a strong plus. So is being able to explain an infrastructure trade-off and what it costs to someone who does not work in infrastructure. Experience with regulated customers is useful but not required.

We do not expect you to be fluent in all of the above, and some of it will be learned on the job. If you have the depth in AWS and identity, and an instinct for where a boundary belongs, apply and we will talk about the rest.

What this role is not

It is not a support desk for product infrastructure, and it is not a compliance role. Teams keep their own infrastructure, architecture sits with our Chief Architect, and ISO 27001 sits with our GRC function. You implement and evidence controls, you do not own the framework. Security inside the product codebases stays with the developers who write them, and so do fixes to it.

It is not a rotation. You own detection and design the escalation path, and incident resolution sits with the teams that own each service. That split runs through the job: you set the standard and spot when something is off, and the teams act inside their own boundary. You tell them a component needs scaling, they scale it.

One honest exception. There is no rota, but this is the platform layer, so occasionally something will escalate outside working hours and you are the person who can help. It is infrequent and it is not a shift pattern. We would rather you knew that from the ad than found it out in month two.

It is not an AI role either, and it is not an agent platform role. Model choice, agent design, prompts, content policy and what an agent may do unattended sit with our AI and Data chapter. You build and enforce the mechanism, they set the policy. Agents run on the substrate you own, and the teams that build them run them there.

It is a hands-on individual role. If the platform function grows, you are the natural person to lead it, but we are not hiring a manager and we would rather say so now.

What we offer

• A permanent Danish employment contract, pension and health insurance.
• A remuneration package that matches your tasks and qualifications.
• Five days a week in our Copenhagen office, with two work from home days a month as the default. We are on site because most of what engineers learn from each other happens in conversation at someone's desk.
• Colleagues who have shipped software into pharma and know how demanding that audience is.
• Clients whose problems are specific and constrained, which is more interesting than it sounds.
• Occasional office dogs, who expect to be petted.

On the office: being in the room matters for this one in particular, because you are building the layer everyone else depends on and most of that work happens next to other engineers rather than in a ticket.

Applying

If you can recognise yourself in just some of these requirements or skills and simply want to learn the rest, we would love to receive your application. We offer an open environment with freedom under responsibility, where you have the opportunity to grow professionally.

Apply through LinkedIn, or get in touch directly if you would rather have a conversation before a formal application. We read everything ourselves.

If there is a repository, a component library, a design document or a postmortem that tells us more than a cover letter would, send that too.

We review applications continuously and close the role when we find the right person.

No recruiters, please.