DEV Community: Viktor Rozenko

Pure cinema

Viktor Rozenko — Sun, 25 Oct 2026 21:59:21 +0000

Most of what we ship is there to make something work, or stop something going
wrong. A refusal that waits for a human. A graph that is also the firewall. A
rollback that never puts back an old password. Important, and none of it is
much fun to watch.

This one is fun to watch.

Twenty-six seconds, nothing sped up. On the left, Claude Code is deploying a project. On the right, the console has LIVE on and is left alone. Watch the recording on gagarin.cloud.

What you are looking at

On the left, Claude Code working through a deploy: a Postgres, an API, a web
page. On the right, the project page in the console, empty when the clip
starts. The agent runs gg resource add, and a Postgres plate fades in on the
right. It ships the API, and a second plate arrives above the first with an
arrow down into it. It ships the web service, the picture slides
to make room, and a third plate lands on top with its public tag. The three
read RESTARTING for a moment, then one by one turn green, and the line under
the project name goes from "nothing running" to "3 of 3 drifting" to
"3 services, in agreement".

Nobody pressed refresh. Nobody touched the console at all.

How it is done, briefly

There is no feed. The engine answers a status read and pushes nothing, so LIVE
is a re-read on a clock: every five seconds the page asks again, through the
same session and the same path as opening it would. The next read waits for
the last one to finish, so a slow cluster slows the clock rather than piling
reads on itself. A tab you are not looking at reads nothing, and catches up the
moment you look back. The switch is remembered per browser, and it is off
until you turn it on, because a status read asks the cluster about every
workload and we would rather not do that to everybody.

The motion is the part we spent the time on. A re-read that redrew the graph
from scratch would snap: a new service would appear fully formed and
everything under it would jump a rank. Instead a plate that stays slides from
where it was to where it now belongs, with its arrows following. A new one
fades in at its place. One that was destroyed fades out where it stood. When a
plate's reading changes, it rings once in its own colour. The ledger on the
left does the same: rows arrive and leave, and a cost or a replica count that
moves flashes as it does. If your system asks for reduced motion, all of it
settles without the choreography.

Why bother

Because the whole pitch of this platform is that you hand a repository to an
agent and it comes back with an address, and that pitch has a weak moment in
the middle. For a minute or two the agent is running commands and you are
reading a transcript, trusting that each line did what it says.

LIVE turns that minute into something you can see. The agent says it added a
database, and a database appears. It says web now reaches api, and an arrow is
drawn. It says everything is up, and everything is green. The transcript and
the picture agree, or they do not, and you know which before the agent tells
you.

That is a real thing, and it is still not why we built it. We built it because
the first time we watched a project assemble itself on screen while an agent
typed, everyone in the room went quiet, and that seemed worth keeping.

Try it

Open any project at my.gagarin.cloud, press LIVE
in the bar above the graph, and tell your coding agent to deploy something
into it. If you have nothing to hand, the chit-chat recipe
in the recording is a Postgres, an API and a web page, and takes an agent
about a minute.

Then sit back. It is the most relaxing minute in infrastructure.

Originally published at gagarin.cloud.

Leaving Railway in an afternoon

Viktor Rozenko — Sun, 25 Oct 2026 21:59:11 +0000

Gagarin vs Railway says where Railway is the better
pick. Read that first if you have not decided. This post is for the afternoon
after you have: what you type, in what order, and where you lose time.

The project is a common shape. A web service, a worker that reads the same
database, a Postgres with a few gigabytes in it, and a cron job that runs a
report at three in the morning. Each service has a Dockerfile, because Railway
builds from one when it finds one. If yours build with Nixpacks or Railpack,
budget an hour at the start to write two Dockerfiles. Nothing else here depends
on the shape of your code.

The clock below is a budget for a project this size. Yours will differ by the
size of the dump and the state of your DNS.

13:00: Write down what only Railway knows

Three things live on Railway and not in your repository: the environment
variables, the database, and the schedule. Get all three onto your machine
before you touch anything else.

railway variables --service web --kv > web.env
railway variables --service worker --kv > worker.env

Open both files and sort the lines into three piles. Railway's own:
RAILWAY_*, PORT, and any line that references another service with
${{...}}. Delete those. The database: DATABASE_URL, PGHOST and friends.
Gagarin provides those, so delete them too. Yours: Stripe keys, SMTP passwords,
feature flags. Keep those, and split them: one file per vendor for the
secrets, .env.stripe and .env.smtp, and the plain settings left where they
were, in web.env and worker.env. The reason is in the 14:10 step. For a
project this size you end up with about ten lines across the four files.

The database comes out with the tool it went in with:

railway connect postgres   # in one terminal
pg_dump "$DATABASE_URL" -Fc -f before.dump   # in another

A few gigabytes take ten to fifteen minutes. Copy the cron schedule out of the
Railway dashboard while you wait.

13:30: A project, a database, and the data

gg login
gg init shop
gg resource add shop/database postgres --size m

gg init prints the project's id. Write it into .gagarin.json at the root
of the repository and commit it, so the next session, yours or an agent's,
knows which project this code is. A Postgres that a real application depends
on starts at size m; s is for one you develop against.

after gg resource add

Name the Postgres database. A resource on Gagarin hands each service that
depends on it a set of variables prefixed with the resource's own name, so one
called database publishes DATABASE_URL, DATABASE_HOST, DATABASE_USER
and the rest. Your code reads DATABASE_URL today. Name the resource after the
variable and your code stays as it is.

The restore goes through a tunnel that lasts as long as the command does:

gg connect shop/database

It prints the same variables a service would hold, rewritten to point at
127.0.0.1, and keeps the tunnel open until you stop it. In another terminal,
paste the printed URL:

pg_restore --no-owner --no-acl -d "postgres://…@127.0.0.1:5432/…" before.dump

Stop gg connect and the tunnel closes. A restore done this way exposed
nothing, so there is nothing to clean up afterwards.

While you are here, gg resource backup shop/database takes a copy now, and
nightly ones follow on their own. A restore on Gagarin always creates a new
resource and never overwrites one, which is why nobody has to approve it at
three in the morning, and the backups outlive the database by fourteen days
if you ever destroy it.

14:10: The variables, then the two services

On Railway your Stripe key is a line in a variables tab. On Gagarin it is a
resource, the same kind of node as the database, and services declare that
they need it:

gg resource add shop/stripe external --env-file .env.stripe
gg resource add shop/smtp external --env-file .env.smtp

An external runs nothing. It holds values and publishes them under its own
name: a .env.stripe with SECRET_KEY in it makes shop/stripe publish
STRIPE_SECRET_KEY. So the split by vendor at 13:00 was also a rename. Strip
the vendor prefix from each key in the file, name the resource after it, and
your code reads the same variable names it read on Railway. The plain settings
in web.env and worker.env have no secret in them and belong to one service
each, so they ride along on the deploy itself.

Now the services. gg ship builds the directory, pushes the image and deploys
it. The number after the colon is the port the container listens on. Railway
sets PORT for you. Gagarin asks you to say it once.

gg ship shop/web:8080 --context ./web --env-file web.env --deps database --deps stripe --deps smtp
gg ship shop/worker:9090 --context ./worker --env-file worker.env --deps database

--deps is the rest of the configuration. Each one opens the route from the
service to the resource and hands the service that resource's variables in one
step. You write no ${{Postgres.DATABASE_URL}}, because the reference and the
firewall rule are the same declaration. The worker never sees the Stripe key,
because it did not ask for it.

after the two ships

Every arrow in that drawing is a --deps. Nothing else draws one. An arrow
into the database is a route and a password; an arrow into a key is the key.

gg deps add prints the variable names it handed over, so you never guess
what a service now holds. A later deploy that forgets --deps withdraws
nothing: taking an edge away is its own command and needs your approval,
because it is the one change that breaks something and reports nothing.

When Stripe rotates your key, gg resource rotate shop/stripe --env-file .env.stripe rolls every service that holds it. No deploy, and no hunt through
services for the ones that had a copy. The values are never copied into a
service's stored environment either, so gg rollback shop/web puts back
yesterday's image and settings and never yesterday's password.

Two habits from Railway to drop here.

Secrets are not deploy arguments. --env-file on a deploy is for a
LOG_LEVEL, and a deploy replaces that file's variables wholesale, so
web.env is committed and restated on each ship. Anything you would mind
seeing in a commit, a shell history or an agent transcript goes in an external
instead, and the graph in the console then shows which services hold it.

Nothing builds on push. Railway watches your branch and builds when it
moves. Gagarin does not build, on purpose, and says why. Your CI
runs gg ship with a credential from gg creds create, which can deploy,
expires, and cannot delete. The secret goes to stdout alone, so it pipes
straight into a CI secret and never touches a disk or a transcript:

gh secret set GAGARIN_TOKEN --body "$(gg creds create --name "github actions: shop" 2>/dev/null)"

For this project the workflow itself is about twenty lines.

14:40: The cron job

On Railway the schedule sits in a service's settings. On Gagarin a scheduled
job is a gg run with a schedule. It is a job rather than a service: it runs to
completion, and nothing can reach it.

gg run shop/report report:v1 --deps database --schedule "0 3 * * *" --tz Europe/Berlin

Nothing runs now, and gg run returns at once. Tomorrow at three, check it with
gg logs shop/report, or open the project in the console at
my.gagarin.cloud, which keeps a feed of how each
firing ended.

Firings never overlap: a report that runs long delays the next one rather than
running beside it. A firing that fails pushes one notification to your phone,
and the next one that succeeds clears it. And a one-off gg run, say a
migration before a deploy, waits and exits with the script's own exit code, so
CI can stop on a failed migration without a line of polling.

14:50: Check it before your users do

$ gg status shop
project shop  (id k3qm7ebd)

     SERVICE   KIND      SIZE  READY          PORT  REACHES                   IMAGE
  ●  web       service   s     1/1            8080  database, stripe◆, smtp◆  web:1761480212
  ●  └ https://web-k3qm7ebd.apps.gagarin.cloud
  ●  worker    service   s     1/1            9090  database                  worker:1761480250
  ◷  report    job       s     ⏱ 0 3 * * *    —     database                  report:v1
     └ next in 12h
  ●  database  postgres  m     1/1            5432  —                         postgres:17
  ◆  stripe    external  —     —              —     —                         —
  ◆  smtp      external  —     —              —     —                         —

  ● running   ◷ scheduled   ◆ external (runs nothing; declaring it grants its variables, not egress)

The REACHES column is the firewall, printed. The plain edges open a route
inside the project. The diamond edges hand over a key and open nothing, since
anything in a project can already reach the internet. The worker has no
address because nobody asked for one, and it cannot acquire one by accident.

gg is not the only window onto this. The console at
my.gagarin.cloud draws the same project as a live
graph, with each service's status, logs and history beside it, the bill for
the month so far, and the switch that sends a push to your phone when a
service goes down or the report fails at three in the morning. Everything the
console shows is something gg can read, and the drawings in this post are
the console's drawings.

If something is wrong at this point, gg status tends to say what. A
container killed for memory gets a line naming the size to move to. A crash is
in gg logs shop/web, with the crashed container's output kept rather than
lost with the pod, and --since 2h --grep "panic:" narrows it. A deploy you
regret is gg rollback shop/web, one call, recorded as a new revision so the
history keeps the evidence.

The web service already has a generated address. Open it, sign in, and click
through the pages that touch the database. Expect to find one thing of your
own here. Ours was a report that assumed TZ was set, because Railway's base
image set it and our Dockerfile did not. One line in the Dockerfile, one more
gg ship.

15:20: The address

gg domain add shop/web shop.example.com

It prints the DNS record to create. Make the change at your registrar, and the
certificate arrives once the record resolves. The generated address keeps
working in the meantime, so the service always has a door.

Both addresses answer from then on, and no deploy can ever take either away:
an address is a standing declaration, and forgetting a flag will not remove
one.

the whole project, with an address

One public address, on the one service a browser opens. The worker, the job
and the three resources stay private, and the arrows say who may reach what.

Keep the Railway service running through the DNS change. Lower the TTL on the
record the day before if you can. If you did not, some users reach the old
service for an hour, and the two services write to two different databases
while they do. That hour is the cost of this approach, and the reason the next
step is there.

15:40: Freeze, copy the delta, cut over

For a side project, skip this and lose an hour of writes. For anything with
users, do it.

Put the Railway service into maintenance mode, or scale it to zero.
Dump again and restore again, with the commands from 13:00 and 13:30. The second dump is small.
Flip the DNS record.
Watch gg logs shop/web for a few minutes.

Budget twenty minutes between the freeze and the flip. Most of it is DNS, and
most of that goes away if you lowered the TTL yesterday.

16:30: Keep Railway for a week

Leave the Railway project in place with the service scaled to zero and the
database intact. Idle, it costs close to nothing, and it is the only copy you
have of the state before the move. Gagarin takes its first nightly backup
tonight and keeps fourteen days of them, so by next week you hold a better
copy.

Then delete the Railway project. Railway asks you to confirm in the browser.
Gagarin, should you ever leave in the other direction, refuses a destructive
command until you press a button it emails you, whichever client asked, and
your CI credential cannot ask at all.

Even you cannot destroy the database while a service still declares it: the
refusal names what depends on it. And when you do go, gg eject shop writes
the Kubernetes objects the project runs as, so leaving is a file rather than
a rewrite. The model makes the case for that design. It is
in this post because someone who moved a production database an hour ago cares
a great deal about what can delete things.

The afternoon, totalled

what	time	commands
inventory, dump	30 min	`railway variables`, `pg_dump`
project, database, restore	40 min	`gg init`, `gg resource add`, `gg connect`
variables, two services	30 min	`gg resource add` ×2, `gg ship` ×2
cron job	10 min	`gg run --schedule`
checks, one fix	30 min	`gg status`, `gg logs`, `gg ship`
address, cutover	70 min	`gg domain add`, the delta dump, DNS

Three and a half hours. One line of code changed, and it fixed a bug you were
already carrying. Two new files in the repository: the CI workflow, and a
.gagarin.json that says which project this is.

You give up builds on push and a second region. You get a graph that is the
firewall and the secrets map at once, traffic that costs
nothing, and a platform where the agent that runs your deploys cannot remove
anything until you press a button.

If you would rather not spend the afternoon yourself, the
coding agent you already use can run the same commands. Paste it the
Railway project name and a link to this post. It will ask you to press a button
once, when it wants to delete the old project.

Sources

Originally published at gagarin.cloud.

Assembly required

Viktor Rozenko — Sun, 25 Oct 2026 21:59:01 +0000

A cloud hands you IP ranges, security groups, service accounts, IAM policies,
load balancer listeners and virtual machines. None of those is a place to put an
application. You get to one by assembling them, and the assembly is work: a few
days at the start of a project, an hour or two a week after that, for as long as
the project lives. It bills nothing. It ships no feature. Each team that does it
builds a private platform-as-a-service out of the same parts, and the one they
finish is as good as their best engineer's spare attention, which is not very
good. The other option is to pay an infrastructure salary for the same artifact.

The not-so-fun puzzle

Count the objects in the smallest useful deployment. One container serving HTTP,
one Postgres behind it, on a domain, with TLS.

On AWS: a VPC, two subnets in two availability zones because the load balancer
refuses to start with one, a route table, an internet gateway, a NAT gateway so
the container can reach your package registry, two security groups, a task
definition, an IAM task role, a second IAM role for the thing that launches the
task, a target group, a listener, an ACM certificate with its validation record,
a Route 53 record, an RDS subnet group, a parameter group, a secret, and a log
group. Twenty resources, give or take your tolerance for defaults. Your
application is one line inside one of them. Google Cloud and Azure sell the same
box with different part names.

None of the twenty is difficult on its own. The difficulty is that all twenty
have to agree, and when two of them disagree the system reports a timeout. You
forgot the NAT gateway, so image pulls hang for three minutes and then fail with
a registry error that says nothing about routing. The security group allows 5432
from a CIDR that looks right and covers the wrong subnet. The health check path
returns 302 and the target group calls it unhealthy, so the load balancer drains
the only task you have and the deploy rolls back clean, with no failure to read.

Nowhere in the documentation does anyone promise that a web app with a database
is easy to run. They promise a page for each primitive, and they deliver that.
The convenience was never offered. We supplied it ourselves and then forgot that
we had.

Your time or your money

Google and Stripe employ people whose entire job is the twenty objects. They
have platform teams, internal deploy tools and an on-call rotation to go with
them, and that is a sane way to spend money at their size.

Below that size you choose between two bills. Hire an infrastructure engineer,
who costs about what a senior backend developer costs and writes none of your
product. Or give the work to a backend developer, who does it in the gaps
between features.

Take the second option and look at what the repo collects. A Terraform module
copied from a blog post. A deploy.sh with a set -e at the top and four aws
calls under it. A GitHub Actions workflow that works, then a second one for
staging that drifts from the first within a month. A naming convention somebody
documented in Notion in March. Six weeks later you own a private PaaS with one
customer, no roadmap, and a maintainer who would rather be writing the product.

Yet another cloud wrapper

Say the expertise is in the building and the wrapper is good. I have read
several of these now, at companies with no connection to each other, and they
contain the same verbs. Build an image and push it. Set environment variables
for an environment. Deploy a version. Declare that this service may reach that
database. Print status. Roll back.

Six verbs, written from scratch at each of those companies, because the problem
has one shape and everybody finds it. Writing them again re-derives something
the industry settled years ago. No customer pays for your deploy subcommand.

And you keep it. The provider releases a major version that renames an attribute
you set in nine places. The node image you pinned goes end-of-life. The engineer
who understood the module takes another job, and the module becomes a thing the
team edits by copying the block above and changing a string. Internal tools get
the maintenance that nothing external demands, which is none.

Who's holding the bag?

Most firms with twelve engineers do not want an infrastructure salary on the
books, so the twenty objects land on developers who have never administered a
network. From there it goes one of a few ways.

They learn, on project time. Four days reading VPC documentation is four
days of a developer's salary spent arriving at the line where the application
work starts. They will be competent at it in a year and will have shipped less
in the meantime.

They guess, and some guesses cost money. A security group open to 0.0.0.0/0
because that made the timeout stop. A database whose backups have never been
restored, so nobody knows whether they work. A secret passed as a build argument
and printed into a public CI log. None of these announces itself on the day it
is made.

They hand it to an agent. An agent writes plausible Terraform in a minute,
and plausible is the output that hurts. The plan applies, the service answers
200, and the bucket holding customer uploads is readable by anyone who knows the
name. The agent is working from the same twenty-part box you are, with the same
four ways to change one thing and no single source of truth among them, so it
guesses in the places you would have guessed.

Then the bill arrives, or the data does not stay where you put it, and somebody
signs the incident report. The agent is not on call. Your developer, who was
never an infrastructure engineer and was handed the work anyway, holds the bag.

There's a better way

Raise the primitives to the things you say out loud when you describe the
system. A project. Services inside it. Managed resources. Which service may
reach which. A domain, for the ones the public should see.

gg resource add saas/pg postgres
gg ship         saas/api:8080 --deps pg
gg ship         saas/web:3000 --deps api
gg domain   add saas/web
# => Live at https://web-3cnciet6.apps.gagarin.cloud/

No VPC, because you were never going to express a product decision as a CIDR
block. No security groups: --deps pg opens the one route and hands api the
credentials for pg in the same call, so the route and the password arrive
together or neither of them does. Every service stays private until gg domain add, which puts the public internet behind a command you have to type rather
than behind a default you have to remember.

What this does not buy you: containers still crash-loop, and migrations still
fail to apply. One class of failure leaves, the class where twenty parts have to
agree and the system tells you only that something, somewhere, timed out.

And when the project outgrows us, gg eject writes out the
Kubernetes you would have had, which you then own, knobs and all. The reasoning
behind all of this is in why coherence, and the objects themselves
are in the model.

We are on call for the platform. You are on call for your code. The line sits
where you can see it, which is more than the twenty objects ever offered.

Originally published at gagarin.cloud.

Two strangers' repos, deployed by agents, unaided

Viktor Rozenko — Sun, 25 Oct 2026 21:58:51 +0000

The claim this platform is built on is that a coding agent can take an application
to production on its own. That is easy to demonstrate on our own code, which is
exactly why demonstrating it on our own code proves nothing.

So: two repositories found on GitHub, cloned cold, neither of them ours and
neither of them seen before. One a Node service with a Python ML sidecar, the
other a .NET 8 app that needs Postgres. Two agents, each given the gg skill and
nothing else — no runbook, no hints, and nobody to ask.

Both of them got there.

the repo	outcome	wall clock	`gg` calls
Node + Python ML sidecar	1/1, verified serving	15m20s	19, zero errors
.NET 8 + Postgres	1/1, verified serving	24m36s	~48, half of them polls

The part worth more than the times: neither agent accepted 1/1 as proof. A
private service on Gagarin has no public address, so each one built a probe image,
ran it as a job inside the project, and went and got a real HTTP response out of
the thing it had just deployed. Nobody told either of them to do that. They did
not trust the status line, which is the correct instinct about a status line.

That is the central claim, tested against strangers' code, and it held. Worth
saying plainly, because everything below is a list of what went wrong.

Six defects, in forty minutes of agent time

Deploying someone else's unfamiliar app is the best bug-finder we have, and it is
not close. Every one of these is ours, not theirs.

A crash reported as SIGSEGV when it was nothing of the kind. An ordinary
unhandled exception in the app surfaced as exit 139, which reads like a corrupt
cross-architecture build — so the agent went looking for an image problem that did
not exist. gg logs had the real stack trace the whole time. Status was lying
with the truth.

A dependency that was declared and did not route yet. A service crash-looped on
a database timeout, with the edge declared and visible in gg status the whole
time. The NetworkPolicy had not converged; it healed itself two minutes later. Our own
diagnosis table attributes that exact symptom to a missing edge, so the
documentation pointed firmly away from the answer.

No way to reach a private service. The strongest signal of the whole exercise,
because both agents hit it independently and both invented the identical
workaround — build a probe, run it as a job, curl from inside. Two strangers
converging on the same workaround is not a missing convenience. It is a missing
feature, and it is ours to ship.

Undocumented Postgres privileges. What the role we hand you can and cannot do
is decisive for EF Core, and for Rails and Django after it, and the only way to
find out is to connect and ask Postgres yourself.

Volume ownership for a non-root container. Undocumented, irreversible, and not
something an agent can fix from outside the container. The agent read the
situation correctly and deployed the app without the volume it wanted, which is
the right call and a bad outcome.

And a sixth, fixed the same day: gg destroy could not delete a job. It routed to
the resource path and printed a raw API endpoint as the workaround, which is the
platform admitting out loud that it has a seam in it.

Five of those six are still open as we publish this. They are written down, they
are ours, and none of them is the kind of thing a demo on our own repository would
ever have found.

Booting is not demonstrating

The .NET app reached 1/1 and cannot do anything.

It needs six third-party API keys, and they fail lazily — not at boot, but the
first time a request actually wants one. Those are a stranger's accounts. No agent
can invent them and neither can we.

This matters more than it looks, because "I deployed your project" is a sentence
we were about to go and say to people. It is true for a self-contained repo and
misleading for anything that calls paid APIs, where the honest version is "it
builds and boots, and you would need your own keys" — a much weaker gift. The tell
is greppable, which is the useful part: read the .env.example before you spend
the afternoon.

And one thing this cloud cannot host

A third candidate was examined and not attempted: a realtime voice bot, WebRTC,
media over UDP. Signalling is HTTP and would pass our ingress fine. The media
would not: a service here gets one TCP port behind an HTTPS ingress, and that repo
expects to be handed real ports on the host.

Kubernetes is not the constraint — a Service takes UDP, and plenty of clusters run
media on one. The constraint is our own model, and it is a product decision rather
than a limit of the substrate. Two true things follow from it. Native UDP is a real
feature with a real cost, because ICE wants a port range and a routable candidate
address, which is the exact thing a managed platform exists to take away from you.
And relayed media already works today, undocumented: egress here is open, so a
service can dial an external TURN relay outbound and media flows
browser → relay → service with no inbound UDP at all. That sentence belongs in our
docs and is not in them yet.

Better to say where the edge is than to find out from somebody who already left.

What we take from it

Forty minutes of agent time bought six defects, a documented ceiling on what we
can honestly promise, and a product boundary we had not named. We will run it
again — as a product test, not as a marketing stunt, which is what it would quietly
become if we let it.

The claim survived. The platform around it picked up five open tasks, which is
the trade we would make again.

Originally published at gagarin.cloud.

A database, two services and an address, in five commands

Viktor Rozenko — Sun, 25 Oct 2026 21:58:42 +0000

Everything below is one project, built from an ordinary repository with no
Gagarin-specific anything in it. No manifest, no config file, no YAML: there is
nowhere on this platform to put one, which is the point and is also why this post
is short.

The app is a Go API, a web front end that calls it, and a Postgres under both.
Call the project feed.

1. The Dockerfile is the only file we need

If your repository already builds an image, you are done before you start. Ours
is the usual two-stage build:

FROM golang:1.25-alpine AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /out/feed ./cmd/feed

FROM gcr.io/distroless/static:nonroot
COPY --from=build /out/feed /feed
EXPOSE 8080
USER nonroot
ENTRYPOINT ["/feed"]

Two things about it matter here and nothing else does. It listens on one TCP
port, and it reads its configuration from the environment. That is the entire
contract — anything that satisfies it runs here.

2. The project, and the database under it

gg init feed
gg resource add feed/pg postgres

gg init creates the project everything else is named for. gg resource add
provisions the Postgres and, more to the point, keeps the credentials. Nobody
types a password into anything after this, and no connection string goes near a
repository.

3. Ship it

gg ship builds the current directory, pushes the image and deploys it — three
commands' worth of work, and they are still there separately for the day you want
them apart.

gg ship feed/api:8080 --deps pg
gg ship feed/web:3000 --deps api

The number after the colon is the port the container listens on, and --deps is
the whole of the configuration: it says what this service may reach, and the
platform hands it the connection variables of any resource in that list. The
database password is never typed and never committed.

Note what is not in those commands. No replica count, no rollout strategy, no
health-check path, no ingress class, no namespace, no service account, no
NetworkPolicy. All of those exist underneath — this is Kubernetes down there —
and none of them is a decision worth making at this point in the afternoon.

4. Nothing reaches anything it has not declared

This is the part people are usually surprised by, and it is the part worth
reading twice.

A private service is default-denied. Until the edge is declared, the call is
dropped — and a dropped packet hangs, it does not fail fast.

--deps declared them on the way past. The graph also moves on its own, without
a deploy:

gg deps ls  feed/api
gg deps add feed/api pg
gg deps rm  feed/api pg

Adding an edge is yours. Taking one away asks a human to approve it, because
it is the one change that breaks something and reports nothing: the service keeps
running, the status stays green, and the call simply stops arriving.

The graph is not a picture drawn from variable references after the fact. The
graph is the firewall.

A migration is not a service

A job runs to completion and listens on nothing. Same image, run once, reaching
the database the same way:

gg run feed/migrate feed:2026-09-01 --deps pg

gg run waits, prints what the job wrote, and exits with the job's own exit
code — so CI can branch on it as though it had run the migration itself.

5. An address

gg domain add feed/web feed.example.com

Certificate and ingress come with it. Leave the domain off and the service gets a
generated one on apps.gagarin.cloud instead.

A resource cannot have an address. Ask anyway, and the engine says so rather than
doing something clever:

{
  "error": {
    "code": "not_a_service",
    "message": "pg is a postgres resource, not a service",
    "fix_hint": "a resource is reached from inside the project by name and is never public"
  }
}

Every error carries a stable code and a fix_hint. Branch on the code, never
on the prose — the error contract is the whole list.

What it looks like once it is up

$ gg status feed
project feed  (id eqteoeay)

    SERVICE  KIND      SIZE  READY  PORT  REACHES  IMAGE               VOLUME
  ● api      service   s     1/1    4000  pg       api:1788569515      —
  ● pg       postgres  s     1/1    5432  —        postgres:17-alpine  10GB
  ● web      service   s     1/1    8080  api      web:1788569576      —
    └ https://feed.gagarin.cloud
    └ https://web-eqteoeay.apps.gagarin.cloud

  ● running
  $0.789 today so far

One screen: what runs, what it reaches, what it costs today. The REACHES
column is the firewall, printed.

A different project in the console — the same reading, drawn. There is nothing to press that is not also a command: one source of truth, and a second way to change it is exactly what we are not building.

And the command it will not run

The database has a service depending on it now. Ask for it to be destroyed and
the answer is no — not a confirmation prompt, not a --force, just no:

gg destroy feed/pg → 409 service_in_use, naming what holds it, and the hint is the command that would let go first. Same graph as step 4, read from the other end. Watch the recording on gagarin.cloud.

The whole afternoon:

step	command	what it is
1	—	your Dockerfile, unchanged
2	`gg init` + `gg resource add`	a project, and a Postgres
3	`gg ship` ×2	two services, and the edges between them
4	`gg deps`	the graph, when it moves without a deploy
5	`gg domain add`	the address

Five commands, and the only decision in them was which service gets a port.

If you want to follow along with your own repository, gg login prints a link
and a code, and there is $5 on a new account to spend. If you want to
know what happens the day you want out, we wrote that down too:
leaving.

Originally published at gagarin.cloud.

Bloated Clouds, Anyone?

Viktor Rozenko — Fri, 18 Sep 2026 19:25:58 +0000

TL;DR

Conventional cloud platforms had to serve everyone, and they became bloated with features. Chasing the next big thing, they abandoned any attempt at improving developer experience, which is the reason clouds blew up in the first place. Big tech companies have the money to pay for DevOps. The rest of us have to choose between wasting developer time on it or delegating it to an AI agent that can't be held responsible when it all comes crashing down.

You can rent a plain VM, but

regular deployments have to arrive via SSH or some elaborate CI setup (we'll look at the options in the next post),
you'll be paying for more compute than you actually use,
and when your service becomes popular enough to use its entire CPU/RAM allowance, you have to scale it up manually.

You can go serverless and it will scale up and down automatically, but

servers with stateful functionality will underperform (for instance, Next.js has server-side caching, and it doesn't work when you run it as a scale-to-zero container),
Firebase Cloud Functions are public by default and weird to set up (they have their own CLI just to package and deploy them, and only JS/Python are allowed),
a few providers let you create a cloud function right in the cloud console. That's terrible, because it's a piece of code that lives in a weird online editor and isn't type-checked against your latest code changes. You will forget to update it sooner or later, and it will crash with a bug.

Suppose you do want the scalability, smooth CI deploys that just make sense, and all your code living in a GitHub repo you control. Welcome to Kubernetes and the 4,000 lines of YAML config that come with it.

Welcome to provisioning a Docker image registry.
Welcome to setting up Traefik for TLS termination.
Welcome to setting up security groups and service accounts.
Welcome to configuring ingress and egress rules.
Welcome to not understanding why this call from "web" to "api" times out. (Is it egress, ingress, or both? Or is it because the "api" service link you put into the "web" env is cluster-local, and "web" lives in a different cluster?)

I can hear you thinking, "Claude can do that for me, no problem," and you're right... but every time? For every project you start from scratch? And remember, all this setup bought you a nicer dev experience (aside from having to set it up and maintain it), but Kubernetes runs on top of real VMs! So the money problem isn't solved. It might even have gotten worse!

Here's what I came up with

Put your Next.js app on Vercel (for most of us, their $20/mo tier is enough).
Provision managed resources (Postgres, MongoDB, Kafka, RabbitMQ, etc.) from DigitalOcean, Supabase, Scaleway, AWS, or Google Cloud. It doesn't really matter which; they all offer good SLAs.
Put your API on DigitalOcean or Scaleway, either as serverless or on App Platform.
Set up a GitHub Actions workflow (lint + test + build + deploy) as early as possible.

Doing this for every project is still a stretch, but when it's done properly, you can git push to main and it'll just deploy, without having to run your own k8s.

This rant covers only a fraction of what's wrong with today's cloud infra. As a developer, I have to live with it every day. So I said "enough," and now I'm building Gagarin Cloud, where deploying a web app is just:

gg resource add gagarin/pg postgres
gg ship         gagarin/api:8080 --deps pg
gg ship         gagarin/web:3000 --deps api
gg domain   add gagarin/web
# => Live at https://web-3cnciet6.apps.gagarin.cloud/

And a nice dependency graph is included: