Cloud and DevOps
AWS infrastructure and delivery pipelines you can understand
We set up and run the infrastructure behind your apps: AWS accounts, CI/CD, environments, backups and cost reviews. Everything is defined as code and lives in accounts you own.
Who it's for
Clients usually come to us for cloud and devops in one of these situations.
Deploys are manual and risky
Releases depend on one person running commands on a server, so they happen rarely, late at night, and with a knot in someone's stomach.
The AWS bill keeps growing
Costs rise every quarter and nobody can say which service, environment or experiment is responsible.
You've outgrown a single server
Your app, database, cron jobs and file uploads share one machine or shared hosting, with backups nobody has tried to restore.
What we build
Good infrastructure work is mostly invisible. Deploys are boring, backups are tested, and the monthly cloud bill doesn't surprise anyone.
- AWS account setup
- Multi-account structure, IAM roles with least privilege, networking, logging and guardrails following AWS's Well-Architected guidance.
- CI/CD pipelines
- Automated build, test and deploy on every merge, with preview environments per pull request and one-click rollback.
- Infrastructure as code
- Terraform or AWS CDK for every resource, reviewed in pull requests like application code, so changes are tracked and repeatable.
- Databases and backups
- Managed PostgreSQL with automated backups, point-in-time recovery and restore drills that prove the backups work.
- Cost reviews
- A line-by-line review of your cloud bill with right-sizing, reserved capacity and cleanup recommendations, then the changes applied.
- Migrations
- Moving apps from shared hosting, a single server or another cloud to AWS, planned in stages with a tested rollback path.
How we approach it
Every request moves through the same steps, inside your weekly release cycle.
- 01
Inventory
We document what you run today, who has access and what it costs, and flag the biggest risks.
- 02
Codify
Existing resources move into infrastructure as code so every later change is reviewed and reversible.
- 03
Automate
Builds, tests, deploys and backups run without manual steps. Secrets move into a managed secrets store.
- 04
Review regularly
Cost, security and reliability are reviewed on a schedule, and findings become requests in your queue.
Typical timeline
Engagement timeline
A typical schedule for moving one or two apps into a well-structured AWS setup.
About 8 weeks to cutover
Weeks 1 to 2
Inventory and access review
What runs where, who has access, what it costs, and the biggest risks.
Weeks 2 to 4
Target architecture and IaC
Account structure, networking, compute and database defined in Terraform or AWS CDK.
Weeks 3 to 5
CI/CD and environments
Automated build, test and deploy, preview environments, and secrets in a managed store.
Weeks 5 to 7
Rehearsal and restore drill
A full migration rehearsed on staging, and a database restore tested and written up.
Weeks 7 to 8
Cutover and handover
Production moves in an agreed window with a rollback path, then the runbook is handed over.
Typical for a Growth plan. Larger estates are planned in waves, one service or environment at a time.
What you get every week
Releases happen on a fixed day each week. Monday starts with a queue check; Friday ends with these in your inbox and your shared channel.
Reviewed infrastructure changes
Every change arrives as a pull request with a plan output, so you can see exactly what will be created, changed or removed.
Change log
A plain-language list of what changed in your environments this week and why.
Cost snapshot
Spend by service and environment compared with the previous week, with anything unusual called out.
Pipeline and backup status
Deploy success, failed jobs and the result of the latest backup checks, in one short summary.
Quality standards
The targets we hold this work to, and how we check them. These are our commitments for how the work is done, not certifications.
- Infrastructure as code
- Our targetEvery resource defined in Terraform or AWS CDK, with no manual console changes in production.
- How we checkChanges go through pull requests, and drift detection flags anything changed outside code.
- Least-privilege IAM
- Our targetRole-based access, no long-lived access keys for people, and multi-factor authentication required.
- How we checkAccess inventory reviewed regularly, with IAM Access Analyzer findings addressed.
- Backups
- Our targetAutomated, encrypted daily backups, and point-in-time recovery for production databases.
- How we checkScheduled restore drills with written results, so backups are proven rather than assumed.
- Deploys
- Our targetAutomated deploys with health checks and one-step rollback.
- How we checkEnforced by the pipeline; production can't be changed from a laptop.
- Observability
- Our targetLogs, metrics and alerts for every service, routed to the people who respond.
- How we checkAlert routes are tested when they're set up and after changes.
- Cost visibility
- Our targetEvery resource tagged by app and environment, with budgets and anomaly alerts.
- How we checkA weekly cost snapshot, and a quarterly cost review on the Scale plan.
Typical deliverables
What you can expect to have in hand, in accounts and repositories you own.
- Infrastructure as code in your repositories
- CI/CD pipeline with preview environments
- Architecture diagram and runbook
- Backup policy with documented restore tests
- Cost report with savings applied
- Access inventory and least-privilege IAM roles
Illustrative example, not a client case study
Example engagement
A SaaS company moves off one large server
Picture a software company whose app, database, background jobs and file uploads all run on one large virtual server, configured by hand years ago. Deploys are manual and backups have never been restored.
Weeks 1 to 2
Find everything
We list every process, cron job, secret and file path on the server, including the ones nobody remembered, and agree on a target setup.
Weeks 2 to 4
Write it as code
Networking, containers on ECS, PostgreSQL on RDS, S3 for uploads and Secrets Manager are defined in Terraform in the company's repository.
Weeks 4 to 6
Automate and rehearse
The deploy pipeline goes live, staging mirrors production, and a database restore is tested and documented.
Weeks 6 to 8
Cut over
Production moves in a planned window. The old server stays available as a fallback for an agreed period, then is retired.
Where it ends up
Every resource is defined in code the company owns, deploys run on merge with rollback, backups have a documented restore test, and costs are tagged by environment.
Technologies we use
A short, well-known list. We'd rather know a few tools deeply than list every framework we've touched.
| Area | Tools |
|---|---|
| AWS | ECS and Fargate, Lambda, RDS, S3, CloudFront, CloudWatch |
| Tooling | Terraform, AWS CDK, Docker, GitHub Actions |
| Our products | Papel Cloud, Papel Monitor |
Which development plan fits
Cloud and DevOps is delivered under a development subscription. These are the plans that suit this work best.
Growth
$790 per month, best fit
Papel Cloud and Papel Monitor are included, so hosting, deploys and alerting are covered from the start.
Start with GrowthScale
$1,490 per month
Adds a quarterly architecture and cost review and a 99.9% uptime SLA on hosted apps.
Start with ScaleEnterprise
Custom quote
For dedicated AWS accounts, specific regions, VPC peering and a custom SLA.
Talk to sales
Common questions
If yours isn't here, ask us on a call or by email.
Do we need to use Papel Cloud?
No. We're equally comfortable working in your own AWS account. Papel Cloud is an option for teams that would rather not manage AWS directly.
Who owns the AWS account?
You do. We work through IAM roles you grant us and can revoke at any time. Infrastructure code lives in your repositories.
Can you lower our cloud bill?
Often, yes, though we won't promise a number before we've seen the bill. The cost review lists each recommendation with its expected effect, and you choose which ones to apply.
Terraform or AWS CDK?
Terraform when you want one tool across several providers or already use it; CDK when your team prefers writing infrastructure in TypeScript. If you already have one, we'll keep it.
Do you work with Azure or Google Cloud?
Our infrastructure work is focused on AWS. If most of your estate is on another cloud, we'll tell you on the first call whether we're a good fit.
Can you provide out-of-hours on-call?
The Scale plan includes 24/7 response for critical incidents on hosted apps, as set out in our Service Level Agreement. Enterprise plans can agree custom support hours.
Talk to an engineer about cloud and devops.
A 30-minute call with an engineer, not a sales script. You'll leave with a scope, a plan recommendation and a start date.