Mid DevOps Engineer (Security and Reliability)
About this role
Mid DevOps Engineer (Security and Reliability)
Physitrack PLC · Fully remote, based in Poland Contract: B2B contractor, EUR 6,000-8,000 per month
About us
Physitrack PLC builds digital health software used by clinicians, physiotherapists and employers in over 100 countries. Our two product lines, Physitrack (exercise prescription, telehealth and patient engagement) and Champion Health (workplace wellbeing), run on a multi-region AWS platform serving Europe, the UK, North America, Australia and the Middle East.
We are ISO 27001:2022 certified. We hold clinical data and a large proprietary content library, and both need defending properly.
The role
You will own the security and reliability surface of our infrastructure: the edge, the data layer, and the observability stack that tells us when either is misbehaving. It sits where security engineering meets SRE. You will design controls at the edge, harden our cloud posture, make sure we can see what is happening across a multi-region estate, then evidence all of it to auditors and enterprise customers. This is hands-on engineering, not a governance role.
We are recruiting two senior infrastructure roles. This one covers the edge, observability and cloud security posture. The other, Senior DevOps Engineer (Platform), covers the Kubernetes estate, delivery pipelines and migrations. Apply for whichever fits, and tell us if both do.
What you will do
Edge and network security
Own our Envoy based edge, along with WAF rules, rate limiting and bot management across our cloud and CDN layers
Design and tune protections against abuse, including content scraping, credential attacks and traffic anomalies
Build detection for the traffic patterns that matter, and keep improving its signal to noise ratio
Cloud security posture
Harden our AWS estate: IAM boundaries, least privilege access, threat detection and runtime monitoring on EKS
Manage secrets, certificates and token lifecycle across the platform
Produce the infrastructure evidence behind ISO 27001 audits, penetration tests and enterprise security reviews
Data platform
Run PostgreSQL and RDS in production across regions, covering upgrades, performance, encryption and access control
Own our search infrastructure, Typesense and vector search, end to end
Work with MongoDB and Elasticache alongside the primary data stores
Observability
Own the monitoring platform: Grafana, Loki and Prometheus, plus Sentry and PagerDuty
Build alerting people actually trust, with meaningful thresholds, low noise and clear runbooks
Improve how logs and metrics flow from the edge and the application into the stack
What we are looking for
Essential
5+ years in infrastructure, SRE or security engineering, with strong AWS depth
Real experience with edge, WAF or reverse proxy technology: Envoy, nginx, Cloudflare, ModSecurity, Coraza or equivalent
Production Kubernetes, ideally EKS, and strong Terraform
Operating PostgreSQL at scale. You have done upgrades and performance work, not just connected to one
Practical observability experience. You have built alerting that worked, and killed alerting that did not
A security engineer's instincts. You think about what an attacker does with the thing you just shipped
English at a working professional level. Our engineering team is international
Nice to have
Search infrastructure: Typesense, Elasticsearch, OpenSearch or vector search
Content protection and anti-scraping work
Having supported ISO 27001, SOC 2 or similar audits from the technical side
Healthcare, fintech or another regulated domain
Polish. Much of the engineering team is in Poland, though the company works in English
How we work
On-call. We run a 24/7 rotation through PagerDuty, with documented playbooks and readiness checklists. Participation is agreed with you rather than assumed, and separately compensated.
Cadence. Written async updates, a fortnightly planning touchpoint and a regular infrastructure and security sync. You set your own hours and choose your own tools.
Documentation. Threat models, decision records and runbooks are part of the work. We expect the reasoning to be written down, not just the config.
Autonomy. Small team, wide scope, very little process between you and a decision.
Originally posted on Himalayas
