Site Reliability Engineer

AWS · TypeScript · Reliability · Security · Scale
Reliability, scale, security, and cost are all yours.
Otto builds an AI computer.
Our hardware sits on a customer's desk running embedded Linux, maintains a live connection to our cloud, and receives signed over-the-air updates from us.
Every part of that path runs on AWS. Our infrastructure is infrastructure-as-code, and our stack is heavily TypeScript.
You will design and operate the platform behind Otto: cloud infrastructure, CI/CD, observability, fleet reliability, security, capacity planning, and cost.
You will also write code, review PRs, deploy to production, respond to incidents, and participate in on-call.
This is a small team. There is no infrastructure layer between you and the system.

Infrastructure as Code
AWS CDK v2
TypeScript
VPC
IAM
Compute
AWS Lambda
ECS Fargate
API Gateway
CloudFront
Data
RDS PostgreSQL
DynamoDB
ElastiCache / Redis
S3
Delivery
GitHub Actions
Docker
ECR
Canary, rolling, and blue/green deployments
Automated rollback
Observability
CloudWatch
OpenTelemetry
Grafana
SLIs / SLOs
Alerting and incident response
Nearby Stack
Node.js
Next.js
Vercel
Some of our web surfaces run on Vercel. Experience with it is helpful, but not required.
What You'll OwnProduction Infrastructure on AWS
Design, build, and operate our production infrastructure across Lambda, Fargate, RDS, ElastiCache, DynamoDB, S3, CloudFront, API Gateway, VPC, and IAM.
You should be comfortable owning the system end to end rather than relying on a separate platform team.
Infrastructure as Code
Every resource lives in our CDK tree.
Development and production environments should be reproducible from the same code, with infrastructure changes reviewed through the same PR process as application code.
CI/CD
Build and maintain GitHub Actions pipelines for:
Application deployments
Container deployments
Infrastructure deployments
Database migrations
Canary releases
Rolling deployments
Blue/green deployments
Automated rollback
You should know when each deployment strategy is appropriate and why.
Observability
Own metrics, logs, traces, dashboards, and alerts across the platform.
The goal is simple: page a human only when a human is actually needed.
SLIs, SLOs, and Error Budgets
Define reliability targets, track them, and help the product and engineering teams make informed decisions when reliability budgets are being consumed.
Incident Response
Lead incidents when they happen.
Run blameless postmortems and turn findings into real reliability work rather than documentation that gets forgotten.
OTA Updates to the Otto Fleet
Our releases eventually reach physical devices sitting in customers' homes and offices.
You will help own:
Canary rollouts
Rollback detection
Fleet health monitoring
Release safety
Failure recovery
A bad release can reach hardware we cannot physically access, so deployment discipline matters.
AWS Cost
Own infrastructure efficiency and visibility.
This includes:
Rightsizing
Spot and reserved capacity
Tagging discipline
Budget alerts
Cost attribution
Identifying which services and workloads are actually driving spend
Security
Help establish and maintain a strong production security posture, including:
IAM least privilege
Network segmentation
Secrets management
Patching
Access controls
Auditability
Foundations for SOC 2
Data Infrastructure
Operate PostgreSQL, Redis, and DynamoDB in production.
That includes:
Backups
Tested restores
Capacity planning
Upgrades
Performance
Availability
Failure recovery
Killing Toil
If something repetitive can be automated, automate it.
Build internal tooling in TypeScript or Bash that allows engineers to self-serve instead of relying on manual infrastructure work.
Mentoring
Help raise the operational and reliability bar across the entire engineering team.
Must Have
These are not "familiarity with" requirements.
We are looking for someone who has owned these systems in production and understands where they fail.
AWS CDK
Deep, current experience with AWS CDK v2 in TypeScript, including:
Constructs
Stacks
Cross-stack references
Cross-region architecture
Custom resources
Deployment troubleshooting
Managing infrastructure changes safely in production
You should know what to do when the synth is clean but the deployment still isn't.
AWS in Production
Strong hands-on experience with:
VPC architecture and networking
IAM policy design
CloudFront
API Gateway
S3
Production security and access controls
We are looking for direct ownership, not experience where another platform team handled the difficult parts.
AWS Lambda
You should understand:
Cold starts
Concurrency limits
VPC-attached functions
Bundle size
Scaling behavior
Timeouts
Connection management
The problems Lambda creates when talking to PostgreSQL
RDS PostgreSQL
Experience actually operating PostgreSQL in production, including:
Query plans
Indexing
Vacuum behavior
Connection limits
RDS Proxy
Major-version upgrades
Point-in-time recovery
Backup and restore procedures you have actually tested
DynamoDB
Strong understanding of DynamoDB data modeling, including:
Designing around access patterns
Partition keys
GSIs
Hot partitions
Conditional writes
On-demand vs. provisioned capacity
TypeScript and Node.js
You should write real production TypeScript, not just infrastructure glue.
Our infrastructure, backend, internal tooling, and device runtime are all heavily Node.js and TypeScript.
You will regularly read and review code outside of a traditional infrastructure role.
Linux and Networking
Strong understanding of:
TCP/IP
DNS
TLS
Load balancing
WebSockets
Linux systems
You should be comfortable debugging problems like a persistent socket that only drops for customers on one ISP.
CI/CD and Incident Response
You should have experience:
Building deployment pipelines
Choosing deployment strategies
Running production incidents
Writing postmortems
Establishing SLOs
Turning incidents into reliability improvements
Bonus
These are not required, but they count for a lot.
Next.js, including App Router, Server Components, and build pipelines
Vercel, including projects, preview environments, edge configuration, and hosted infrastructure
Edge, IoT, or embedded Linux fleets with OTA updates
Redis pub/sub
Large-scale WebSocket services
AWS Organizations and multi-account architectures
OIDC deployment roles
Ephemeral per-developer environments
LLM gateways, proxies, or AI workloads on AWS
SOC 2 or ISO 27001 experience
FinOps experience
Self-hosted CI runners
Container build caching
Kubernetes experience — useful context, although we do not currently run Kubernetes
AWS certifications such as Solutions Architect, DevOps Engineer, or SysOps Administrator
What This Is Really Like
Otto is a small team with a short path from decision to production.
You will work in the same repositories as the rest of the engineering organization and regularly read code outside your lane.
Our systems span cloud infrastructure, APIs, data infrastructure, web applications, and physical devices running in the field.
We value clear technical writing.
Design documents, postmortems, architecture decisions, and the sentence in a PR explaining why something is changing all matter.
If a deployment changes something persisted on an Otto device that has been running in someone's home for six months, we want that risk understood and documented before the release goes out.
On-call is shared and real.
In return, fixing the system that woke you up is treated as the work — not as an interruption from the work.
Show more Show less