Cloud and DevOps services, with rollback in place from day one
We set up the pipeline, the monitoring, the backups and the rollback that let a team ship every day without fear, migrate you to the cloud if you are not there yet, and keep it running under a monthly agreement you can end with 30 days’ notice.
A written scope and a fixed budget before any work is billed.
The team that builds it also runs it
Many companies have no one whose job is the production environment. Deploys are manual, backups are assumed, and the first sign of trouble is a customer email. DevOps work fixes that with a small number of habits that have to be in place from the start: every change goes through the same pipeline, every release can be undone, and someone is told when something breaks.
We build that setup into every system we deliver, and we take it on for systems we did not build. If you are moving to the cloud, we plan the migration so the business keeps running, and we leave the infrastructure in your own accounts, described clearly enough that another team could run it.
Moving the application itself to a current stack is legacy modernization. Many projects combine the two.
Sound familiar?
Deploys happen at night, by hand
Releases depend on one person and a checklist, and a bad one means a long night restoring files from somewhere.
Nobody has tested the backups
Backups probably run. Whether a restore works, and how long it takes, is something you would find out during an outage.
Customers notice problems before you do
There is no monitoring or alerting, so errors and slow pages surface as support tickets.
The infrastructure is in someone else’s account
A former contractor or agency set up the servers, and you are not sure you could move them without their help.
What we set up and run
The pieces that make releases routine and outages short.
CI/CD pipeline
Every change runs its tests, gets its own preview deployment for review, and reaches production through the same path.
- CI
- Preview
- Production
Monitoring and alerts
Errors, slow responses and failing jobs reported to the right person before customers see them.
- Monitoring
- Alerts
Backups and rollback
Backups with restores tested on a schedule, and releases that can be rolled back to the previous version.
- Backups
- Rollback
Cloud migration and operations
A planned move to the cloud, autoscaling where traffic needs it, and ongoing operations on a monthly agreement.
- Migration
- Autoscaling
What you keep at the end
Everything below is yours from the first commit, under your own accounts wherever possible. Nothing in it is licensed from us, and nothing can only be maintained by us.
your-company/
- infra/The infrastructure, in your own cloud accounts.
- ci/The pipeline every change runs through, from commit to production.
- monitoring/Dashboards, alert rules and who each alert goes to.
- docs/runbook.mdDeploy, roll back, restore a backup, rotate a secret.
- docs/restore-tests.mdThe record of backup restores, with how long each one took.
Four stages, and what
each one hands you
Every stage ends in something you can review and keep, including the stages that come before any code is written.
Discovery and requirements analysis
We map the real problem before any code is written: stakeholders, constraints, existing systems, and what success means in measurable terms.
- requirements.md
- scope + fixed budget
- risk register
Design and architecture
Interface flows and system architecture designed together, so what we specify is what we can build and scale.
- clickable prototype
- system diagram
- data model
Build, with a weekly demo
Short delivery cycles with visible progress. You review working software throughout, not a finished system revealed on launch day.
- staging deploy / cycle
- test suite + CI
- weekly demo
Launch, then operations
We deploy the system, monitor it, and hand over the runbook. We then continue to operate it under a monthly agreement you can end with 30 days’ notice.
- production infra
- runbook + handover docs
- monitoring + alerts
Terms we put in writing
before work begins
The figures we commit to on every engagement. Your project gets its own dated plan on top of them.
- Inquiry
- 1 business dayA reply from someone who has read the brief.
- Discovery
- 1 to 3 weeksEnds in a written scope and a fixed budget.
- Weekly review
- Every weekThe work as it stands, on a link you can open yourself.
- First release
- 8 to 16 weeksTypical time from the end of discovery to production.
- Operations
- 30 days’ noticeMonitoring and iteration under a monthly agreement.
Illustrative. Every project receives its own dated plan before work begins.
How DevOps work is priced
Setting up or migrating infrastructure is a one-off price, fixed when discovery ends. Running it afterwards is a monthly agreement with a defined scope, which you can end with 30 days’ notice.
- 01How many applications and environments are involved
- 02Whether we are setting up a new environment or taking over an existing one
- 03The size and shape of a cloud migration, including data
- 04Uptime and response expectations for operations
- 05Compliance requirements for logging, access and retention
What we build it with
Tools with long support horizons and large talent pools, so the system stays maintainable by any capable team, not only ours.
Vercel
Every change ships to its own preview URL, so it can be reviewed before it reaches production.
Supabase
Managed Postgres with backups and access rules, where a project fits it.
PostgreSQL
Backups, point-in-time recovery and restore tests on the database that matters most.
Node.js
Services and background jobs that run the same in the pipeline as in production.
Questions buyers ask us
The ones that come up most in first conversations about this service.
Something not covered here?
Email us at hello@kodfabrika.com.
Related services
Built to last.
Started this week.
Tell us what you’re building. You’ll receive a written scope, a defined budget, and a delivery plan. Not a proposal deck.