AI Will Kill Your Project and You Won't Even Notice. Part One: Deploy

A developer recounts the deployment challenges of an AI-powered astrology Telegram bot that never made a cent and was shut down. The project used two microservices and a free database, leading to separate bills and infrastructure complexity. The developer recommends Infrastructure as Code as a lifeline for beginners and praises Fly.io for its built-in IaC and simple deployment.

I've got an idea for a series of posts about our vibe-coding problems. Today I'll talk about the lumps I took in the part that was hardest for me: deploy. My favorite pet project was about astrology: you'd send your birth data to a Telegram bot, the service would calculate your natal chart, and an AI would answer questions about it. In six months the project didn't make a single cent, and one fine day, right in the middle of eclipse season , I shut it down. But along the way it walked me into a decent number of gotchas, and those I want to share. So. You have a brilliant idea for a brilliant service. You talked it over with an AI, the AI produced code and promises of money raining down. Just one small thing left: that code currently lives — and probably works — only on your laptop. And it needs to be on the internet. I see three options, and two of them rule themselves out. Locally, from your own computer. Forward the ports, set up a domain, make sure the machine doesn't fall asleep, figure out security, never turn the laptop off. I can't do that. I'm just a cat. On a rented bare VPS. They hand you a blank box — install the updates yourself, the firewall, the web server, the certificates, the monitoring, patch it all yourself until the end of time. I can't do that either. I've got tiny paws. Which leaves specialized hosting — it takes some of this off your hands. Then the question becomes: which one. I had three. I had two microservices: one calculated natal charts, the other talked to the human via AI. You might tell me this is overkill, but I had a serious, important reason that I may write about in a separate post spoiler: an AI can quietly drag in a dependency whose license forces you to open-source your closed code — and, well, oops . Whatever the reasons, I needed to roll out two microservices, with one facing the internet and the other listening only to the first. Not every host makes that easy enough to set up. By the way, an important note for your wallet: every microservice is a separate bill. Two microservices inside a single project of mine = I pay twice. Keep that in mind when an AI cheerfully suggests "let's split this out into its own service." If you don't have a DB, skip this section. I did have one: I needed to store natal charts, plus subscriptions and payment dates as if there were any . My database was hosted separately, and for free. I'm going to tiptoe past that "for free" for now, because a free DB can become a problem, and that deserves its own post. For now remember one thing: when you're choosing a host, look separately at how it hosts databases. Many charge for it, and free tiers can have nasty surprises. There are hosts that position themselves as "for complete beginners": every setting through a beautiful UI, just click the checkboxes. Sounds great, but I wouldn't. Here's why: you're tied to that host forever — your configuration lives in their UI, not with you; checkboxes have to be watched and ticked by hand, and you have two hands and a memory that leaks; and most importantly — you can't ask an AI to check your checkboxes for you. Code, you can. Which leads to an unexpected conclusion: Infrastructure as Code is the ideal vibe-coder option. Not an advanced topic for DevOps graybeards — it's a lifeline for beginners. Your infrastructure is described in a text file, the file sits next to your code, and you can hand it to an AI and ask, "take a look, did I screw anything up?" You can't check checkboxes that way — first you have to find them all in that beautiful, trendy UI. I tried several hosts. I won't describe the ones that didn't work out — in case of lawyers. But I liked Fly.io http://Fly.io , and here's why: that same Infrastructure as Code, out of the box; deploy with a single command straight from the folder — fly deploy , no git required, no pushes, just from the directory with your code; controls for who talks to whom over the network — which service accepts requests from the internet, and which one only answers another service. This is where their ad would go, if anyone had paid me. Nobody did, so let me tell you about the rough edges too. At first it seemed to me that Fly was magic: it takes my code and figures out how to run it. It didn't invent a thing. It dutifully executed four files that I had written myself beforehand kidding, of course — "myself," the AI wrote them for me : Dockerfile two of them, one per service — I had these from the start, because I never managed to run the astrology calculation library without one. But in general, I sincerely and wholeheartedly recommend doing all local development in containers — it will save your sanity. But alas, you're finally going to have to learn Docker in 2026. fly.toml also two — a description of how the service lives on the platform: name, region, machine size, which ports are exposed, health checks. I'll write about these in detail below. The fly deploy command reads fly.toml from the folder, builds an image from the Dockerfile , uploads it and rolls out a machine with the described parameters. No magic whatsoever. : A reminder of the setup: I have two apps. dearstarsbot — the chatterbox, it faces outward. sweservice — the natal chart calculator, it should listen only to the bot and to nobody else. The chatterbox goes to the calculator for the math. That's the whole topology. The chatterbox app = 'dearstarsbot' primary region = 'fra' build build-target = "bot" env METRICS PORT = "8081" CHART API URL = "http://sweservice.flycast/chart" CITY = "London" OPENAI MODEL = "gpt-4o" SUPPORT CHAT ID = "12345666" http service internal port = 8081 force https = true auto stop machines = 'off' auto start machines = true min machines running = 1 max machines running = 1 processes = 'app' http service.checks interval = "10s" timeout = "2s" grace period = "5s" method = "GET" path = "/health" vm memory = '1gb' cpu kind = 'shared' cpus = 1 memory mb = 1024 Going line by line through what isn't obvious: build-target = "bot" — needed if your Dockerfile has several stages FROM ... AS bot ; then Fly builds not the whole Dockerfile but the specific stage named bot . If there are no stages, you don't need the line. env — this is the non-secret config: the metrics port, the address of the second service, the default city, the OpenAI model, and my personal chat id so I get notifications. Note: no keys here. CHART API URL = "http://sweservice.flycast/chart" — the first wire between the services. This is the address the chatterbox goes to for a chart calculation. Let's break the address down: sweservice is the name of the second app, .flycast is its private address inside my network on Fly, and http:// not https — because flycast only ever speaks http. Remember that http , it'll come up again. internal port = 8081 — the port the chatterbox listens on inside the container. Functionally the chatterbox only has outgoing traffic requests to the Telegram API , but I also had metrics, and this is the port they came out of. force https = true — public service, everyone gets pushed to https. Makes sense. auto stop machines = 'off' + min = 1 + max = 1 — the chatterbox lives in exactly one instance and never falls asleep. Why — I'll explain in the gotchas section. http service.checks — every 10 seconds Fly pokes /health and decides whether the service is alive. This will also come up in the gotchas. vm — the parameters of the machine Fly will run the app on. cpu kind = 'shared' — a shared processor; I'll talk about it a bit further down, but not in the gotchas. The calculator: app = 'sweservice' primary region = 'fra' build build-target = "final" env METRICS PORT = "8080" CGO ENABLED = 1 CITY = "London" http service internal port = 8080 force https = false auto stop machines = 'stop' auto start machines = true min machines running = 1 max machines running = 1 processes = 'app' vm memory = '1gb' cpu kind = 'shared' cpus = 1 Here we mostly look at the differences: CGO ENABLED = 1 — a fairly exotic line, needed only if, like me, you have Go on top of C: inside this service lives a C library for the calculations. If you don't have Go on top of C, forget you ever saw this line. internal port = 8080 — the second wire between the services. Remember CHART API URL = ".../chart" on the chatterbox? Well, /chart lives on exactly this port. The port the calculator listens on is exactly the port the chatterbox knocks on. force https = false — and this isn't an oversight, it's a requirement. flycast only works over http, and if you put true here, the private connection between the services simply breaks. That same http:// from the chatterbox's address, just seen from the other side. auto stop machines = 'stop' — supposedly "let it sleep when nobody's asking." But right next to it sits min machines running = 1 , and that 1 won't let the machine fall asleep. Which means 'stop' here quietly does nothing. Oops.And one more oops: look at both files again and find the line that makes sweservice private. It isn't there. Both services declare http service . Both, if you go by fly.toml alone, are public. Privacy isn't described in the config at all. It comes from somewhere else: sweservice simply has no public IP address — only a private flycast one. Unfortunately, there's no way to do this through fly.toml , only through the beautiful UI or the terminal: fly ips allocate-v6 --private assign a private flycast address fly ips list check that there are no public addresses fly ips release <address remove the public one, if Fly already slapped one on The sneaky part is that on a service's first deploy, Fly slaps a public IP on it automatically. So you're insecure by default — privacy is opt-in, and opting in means going and pulling the address off yourself. Forget, and your internal calculator is hanging out on the open internet. So why can't you manage this from the one place where it would actually make sense — the config file? Great question. Pretty much everyone asks the Fly team that one. It's in the backlog somewhere, I'm sure. An interesting machine setting from my fly.toml or from the UI ; let me explain it. Fly doesn't give you a whole CPU core, it slices it up among a bunch of other people's machines: you're renting not a core, but slices of its time. How many slices do you get? On average — about 6% of one core: as if your processor worked for 3–4 seconds out of every minute. Sounds pathetic, but there's a trick: while you idle, you bank burst credit, and when you need it, you grab a whole core at 100% for several minutes. So shared isn't "always slow," it's "fast in short bursts, slow if you hammer the CPU nonstop." Who this doesn't work for. If I'd spun up some kind of Counter-Strike server on this machine — it loads the CPU continuously, every tick — the burst credit would have burned out in minutes, and after that the game would lag at those very 6%. Anything that uses the processor evenly and without pauses a game server, video transcoding, mining isn't going to survive on shared. For my workloads, though, it's perfect. Calculating a natal chart is about three seconds of CPU, but the operation is one-off: the user calculates once, the result goes into the database, and from then on all questions go to the database, not to the calculator. Even with millions of users ah, if only I'm not worried — I'm not going to get a million new ones per hour, and the old charts are already calculated. The chatterbox barely touches the processor either: the longest thing there is waiting for the AI's answer, and I do that waiting asynchronously, with the CPU free the whole time. Both of my workloads are a burst once in a blue moon, not a constant load. The ideal client for shared. Something else you might think about while ticking this checkbox: I've got real people's data — won't it leak to my neighbor on the core? It won't. You're sharing processor time, not memory: every machine is an isolated VM, and someone else's code doesn't get into your RAM or your database. Anyway, for me this was a really good way to save money — and I took it. Gotcha 1: Keys, or the most expensive self-own. Deploy isn't only "where do I put the code." It's also "how do I put the keys so they don't leak." I had three: the key to the AI provider, the Telegram bot token, the database credentials. Where do you put them? Not in the code and not in fly.toml . A vibe-coding classic: the AI hardcoded a key, you committed it to a public repository, and a couple of days later your balance is zero or negative, because somebody found your key and ran their own workloads on it. Someone might tell me: but you can make the repository private And I'll answer: iCloud is private too, and look how many times it's been breached. Keys should be encrypted, not just sitting in a private place. For this, Fly has a ~~beautiful UI~~ terminal command, fly secrets set fly secrets set OPENAI API KEY=sk-... BOT TOKEN=... The keys get passed into the machine as environment variables at startup and don't end up in the built image. You do this once and forget it, but Fly remembers — in encrypted form. You can look at which keys are already set, but not at the values themselves: fly secrets list will show you only their hashes. NAME DIGEST DATE OPENAI API KEY b9e37b7b239ee4… 2 days ago BOT TOKEN cdbe3268a82bfe… 2 days ago Gotcha 2: But there was a health check right there And Fly did do something with it, just not what I thought. Remember the checks section in my fly.toml , the one that knocks on /health every 10 seconds? That's Fly checking: "you alive in there?" The app answers "yep" — so it's alive, all good. I thought that if it's "not yep," Fly would restart it. But no. It just stops sending traffic to it. There is a restart option, but for that the app has to fall over completely — like, actually exit, with some scary exit code. If it didn't fall over, well, fine then. So there I am drinking tea while somebody breaks my chatterbox, and in such a clever way that it hangs but doesn't crash. /health says "not yep," Fly silently pulls the traffic. And I, you know, have polling — there's no incoming traffic there anyway, which does nothing for me. What helped was a friend who wanted to ask the bot whether he should change jobs. The bot didn't answer. The friend messaged me. Okay, so the gotcha got me. What did I do about it? First, I started calling panic on everything I could — better that the service honestly falls over and comes back by restart policy than that it hangs silently. Second, a backup plan for the unforeseen: once a day I'd message the bot myself and see whether it answered. Mom says I'm a real engineer. Gotcha 3: Keep two machines per service. The host keeps pushing you to run two copies of every service — for reliability. In theory, this would have saved me from gotcha 2: the hung app would go on hanging, its copy would go on answering, and so on until the end of time. But that's in theory, and for most services, not for me. My chatterbox, which polls the Telegram API, has to exist in exactly one instance, otherwise the two copies start conflicting and throwing errors. And now, as I write this, I'm thinking the problem could have been worked around if I'd used a webhook instead of polling — but that's me thinking now, and back then I wasn't thinking that. And by the way, I'd also have had to pay twice as much for two machines. Gotcha 4: Saving money and scale-to-zero. Hosts offer a cheap mode: the service falls asleep when idle and wakes up when a request arrives. Cheaper — yes, because these days billing is most often "by usage." But the first request after the sleep waits several seconds for the wake-up. I didn't even try this: it was immediately obvious to me that for a chatbot, a several-second pause = a lost human. The calculator would have been a great candidate for that kind of savings, but back then I still had money and the hope of making more, so I went straight for the slightly more expensive always-on tier. About $13 a month — for two always-on machines of my size a gig of memory, shared CPU . The shortest section. AI is good. It'll write the code and sprinkle em dashes through your article. It'll make the choice for you too: shared or not, one machine or two — except it'll probably pick whatever the host recommends by default, or whatever counts as normal for everybody, without stopping to think about whether it suits you . So I've collected the places where, at the deploy stage, it's worth stopping to think: each one of them hits either the project or the wallet, and sometimes both at once. Anyway: use your head, and may AI help us all. Argue in the comments. Tell me where I made a good call and where I made a so-so one. Stories of your own vibe-deploying are also welcome.