I finally found a vibe-coding tool I can trust with my home lab, and the AI never sees a single API key

Published Jul 28, 2026, 9:00 AM EDT I’m Adam Conway, an Irish technology fanatic with a BSc in Computer Science and I'm XDA’s Lead Technical Editor. My Bachelor’s thesis was conducted on the viability of benchmarking the non-functional elements of Android apps and smartphones such as performance, and I’ve been working in the tech industry in some way or another since 2017. In my spare time, you’ll probably find me playing Counter-Strike or VALORANT, and you can reach out to me at adam@xda-developers.com, on Twitter as @AdamConwayIE, on Instagram as AdamConwayIE, or u/AdamConwayIE on Reddit. Sign in to your XDA account Getting an AI to write working software is something anyone can do these days, whether it's through Lovable, Claude Code, or any of the other dozen tools that can do the same thing. All you need to do is wait a few minutes, maybe test a thing or two, and have a short back-and-forth with an AI before you get something functional at the end. It might be ugly, but it works. However, a lot less of an AI-coding workflow has been solved than you might think. When your shiny new software needs to talk to something real, it needs credentials or another way to connect to that service. Those often end up in a .env file or a code repository, and stored data can often end up in a conventionally-retrievable database like Supabase, ready and waiting for an attacker to make their move. You're basically handing a system that confidently invents function names the keys to actually important stuff, and using something and trusting it aren't the same thing. Tines has launched its answer to this problem in the form of 3B, which feels like a rebuild of the entire platform rather than a mere update or new product launch. The old platform is still there under the name Tines Stories, but 3B is the future of Tines, and there are supported ways to migrate all of your old Tines stories to 3B. I've had access to it for a while and I've used it to build three things: a rental property tracker, a product price watcher, and a monitoring dashboard for my home lab. They were all designed to test different things, and I got there simply by describing what I wanted. The platform isn't perfect, and funnily enough, a NAS that 3B can't connect to actually can't be connected to because of the entire security stance of the platform itself. As well, the free tier is more generous than what Tines has offered in the past, but it stops with the $50 of AI credits you start with alongside three live workflows, and the first paid tier starts at six figures. But the most impressive part of the entire platform is the fact that not a single API key actually touches the code. A workflow is a folder of code There's no lock-in here, either Building the home lab dashboard meant describing what I wanted, which was something that polled my servers, put their state on one page, and emailed me if a disk filled up or a ZFS pool degraded. That took about twenty minutes in total, counting the back-and-forth it took to get a first version that actually ran. What I got in the end was a six-step piece of software, though these six steps are actually mostly hidden from the user. There's a collector on a two-minute cron, an evaluator that holds per-condition state so an ongoing problem emails once instead of every two minutes, the email step itself, two API endpoints, and a React dashboard with trend charts and a threshold editor. Tines allows you to download all of the code generated with 3B for a given project, so that's what I did. As it turns out, it had also written its own README, complete with a Mermaid diagram of the flow and a table of which hosts were live and which weren't, along with the reasons why. As it turns out, every step in an application gets its own subfolder holding its code, a config.toml, and its own Dockerfile, which means that each step in a workflow is genuinely its own container. The collector and the evaluator in mine are Python running on a standalone CPython build with dependencies pulled in by uv, the email step and both API endpoints are TypeScript on Bun, and the dashboard is React that gets bundled with Bun and styled with Tailwind at build time. All of it was chosen by 3B, and while the result does look fairly "AI slop"-like in design, it's completely functional, and you can guide the design easily if you'd prefer. Each step talks to another step over stdin and stdout, which is as old-fashioned as it gets, and it works exactly as well as it always has. A step reads its input, does what it does, writes the output to stdout, and the output is now stdin for the next step. If you link a single step to three other steps, then all three get the same input and run in parallel. In 3B, "branches" map one-to-one with git branches, and a "draft" gets an isolated copy of any persistent storage, so testing a change is easy. This enables a feature that Tines refers to as self-healing, which really breaks down into two separate things. The first, Autofix, watches execution logs and builds a branch containing a fix whenever it sees consistent errors, while autotune does the same thing but for optimisations, and neither of them touches whatever is currently running. You end up with what is essentially a pull request that you can discard if you don't like it or don't agree with it, and you can disable the feature entirely, too. There's also a CLAUDE.md in the root of every export that points to @AGENTS.md, and AGENTS.md is a 382-line specification of the entire platform written for a coding agent to read. You can take the code and leave Download a bundle, use Git, whatever you want To be clear, you can't just download the code and run it untouched. Every step makes plain HTTP requests and expects something else to attach the credentials for them, which what makes all of this work and is something I'll come back to. When you take the code out of 3B, there's nothing putting an API key on those requests any more. That's a smaller problem than it sounds, though, as fixing it is something an AI coding tool is unambiguously good at. It's ordinary Python and TypeScript with its own requirements.txt and package.json, and the auth is missing from one identifiable place in each adapter. If you give it to Claude Code, you can tell it to read credentials from environment variables and add whatever headers each service wants, and you'll have it running outside of Tines quite quickly. If you're using a tool like 3B, chances are you have something like Claude or Codex anyway. The only thing you'd have to put back on the way out, then, is the security, and the code is portable because it doesn't have any secrets to worry about. I've put the whole export up on GitHub if you'd like to read through it and see the way it's built. The only change I made was to remove my own email that it was sending to. The AI never sees your credentials They're inserted via a proxy In 3B, a credential lives in something called a connector, and connectors are configured well away from any workflow. When a step calls out to a service, that credential is injected into the request by a proxy sitting outside the execution environment entirely, so the code never reads it and can't print it even if you asked. You can see this in what 3B actually wrote for me. My TrueNAS adapter opens like this: """TrueNAS SCALE adapter. Credentials are injected by the connector attached to this step, so requests are made plain. """ And then it goes ahead and does exactly that: req = urllib.request.Request( base_url + path, data=data, method=method, headers={"Content-Type": "application/json"}, ) The auth only appears in transit, and not in the code itself. What this means is that a model that gets prompt injected by a page it fetched or in other ways mishandles data has nothing it can actually exfiltrate. It can use a credential's authority to connect to a service it's allowed to reach, but it can't read the credential itself. Even then, it still has an allowlist of URLs that it can connect to, so it can't connect to the wrong service by accident, and the connectors in Tines' library already fill that in for you. Gmail only permits the two Google hosts that Gmail actually uses, scoped to Gmail's own API paths, rather than waving through all of googleapis.com. That isn't guarding against a hypothetical, either. Roughly one in ten of 1,645 apps published to Lovable's marketplace turned out to be leaking user data through an authorization flaw, and self-hosted tools aren't immune to it, either. Steps don't talk to the host kernel directly There's a custom gVisor implementation Tines says that every step runs in a completely isolated environment, executes, and then disappears, and that cross-contamination between runs or users is architecturally impossible. That's a big claim, and a normal container wouldn't get you there, as Docker by default gives a workload namespaces and cgroups, which is a fence around a process that's still making system calls into the same kernel its neighbours are using. Because of that, I asked what actually runs them, and the answer was pretty impressive. It's a custom environment built on top of gVisor, with credential injection handled at runtime. gVisor is Google's sandbox runtime, and it implements a kernel in userspace that sits between the workload and the real one, so system calls get intercepted and serviced by that layer instead of being passed straight through. The amount of host kernel that a hostile step can touch shrinks enormously as a result. Tines has also been contributing upstream to gVisor, and there are sixteen pull requests by them at the time of writing, covering a warm sentry mode for faster restore cycles, checkpoint and restore support for host networking, composable seccomp filters, and extension hooks so that custom backends can be plugged into the filesystem gofer. It isn't the same as giving every step its own virtual machine, and a gVisor bug is still a real scenario, but it's a lot more than a standard Docker container would give you. My home lab sits behind a tunnel I control from 3B It's a basic Chainguard setup Reaching machines on my own network from Tines' cloud would normally mean port forwarding, a reverse proxy, cursed webhooks, or a VPN, and 3B's answer is a small container that you run at home. It's a Chainguard base image running as a non-root user, it publishes no ports at all, and there's almost nothing inside it, with the whole application being a single 4.5MB static binary. There isn't even an ip command in there, which I found out by trying to run one. How it works is pretty simple: it connects to a gateway on a subdomain specific to my tenant and authenticates with mutual TLS using a client certificate issued by a private CA rather than a shared token, so nothing ever needs to reach in and no firewall rules have to change on my end. There's no VPN interface either, as the container has no NET_ADMIN capability and no TUN device, meaning it can't create a network interface even if it wanted to. It's a userspace proxy that dials out and forwards whatever it's allowed to forward, which suits this workflow a lot better than a VPN would, as a VPN basically brings the cloud to your network and then filters. Finally, there's a variable called DESTINATION_CIDRS, which reads 192.168.1.0/24,192.168.2.0/24 on mine, as that's what I allowed it to access from the Tines control panel. One of my machines wouldn't connect, and the reason is why 3B works It couldn't access the auth, so it couldn't compute the token With some wrangling, I got three of my hosts working with 3B pretty easily, but one that didn't was a Ugreen NAS. UGOS authenticates in three moves, where you ask it for a public key, RSA-encrypt your password with that key and post it back, and it replies with a session token to attach to everything afterwards. I pointed 3B at the Home Assistant integration for it, which is a documented implementation of the authentication flow. It analyzed the integration, read the flow back to me, and it explained the padding scheme and the header that the key arrives in. However, it then told me it couldn't do it. You see, RSA-encrypting a password requires having the password, but that kind of goes against the entire ethos of 3B if you need to computationally compute a token using a credential given by a service. For many services, attaching a credential on the way out works when the credential is something you have to send... it's not so much the case if you need to operate on it, first. It's not that 3B can't do it though; it does, and fairly often. Tines has 1,032 connectors available according to the list it sent to my browser in my tenant, and around 85% place a static secret somewhere, whether that's a bearer token, a header, basic auth, or a query string. Another 54 fetch a token first and then use that, while the last 53 hand off to named schemes that do cryptography with the secret never leaving the proxy, including awsSigV4, oauth1HmacSha1, Akamai's EdgeGrid signing, LDAP binds, and native Postgres, MySQL and MongoDB auth. Request signing works perfectly well here, it's just that the code inside of the containers isn't doing it. There's a generic connector for building your own API connections, and you can handle bearer tokens, custom headers, basic authentication, and query parameters, which are the primary four that cover most of the library already. Tines told me that fully custom auth schemes aren't supported at the moment, though it's something the company is looking at. On the bright side, this means that the architecture isn't fundamentallty incompatible with my Ugreen NAS, but until there's an official connector, I can't pull from it without resorting to something like SSH instead. Practically every mainstream service you can think of is there, though. It's pleasant and easy to use I'll admit that I wasn't expecting to actually love 3B as much as I do, especially given that I have an aversion to vibe-coding in general, and something pitched at security teams with a six-figure entry price has no particular reason to be pleasant to use... but it genuinely is. Everything is "tactile" in the sense that there are little click noises, animations, sounds when it needs your attention, and a general smoothness that can't really be demonstrated in screenshots alone. It's a nice touch, and it feels like a deliberate design from start to finish put together with immense care. There are a ton of decisions that prove how much care went into it; for example, AGENTS.md tells the model not to ask non-technical users technical questions. Instead of asking them to pick volume scope, concurrency, exclusive writers or branch state, it's instructed to ask those users what should happen to the data, who owns it, and who needs to update it. It's not just built for engineers, but it'll happily cater to those users too. And it does a great job at making both co-exist in the same plane. Workflows can also go the other way around, where you set the authentication level on a route and it can publish itself as an MCP server, mkaing it possible for Claude, ChatGPT or anything else to connect it and call it as a tool. You can describe the tool in English, have it built, and then hand it to your local assistant. Pretty neat. Three live workflows and $50 of AI credits completely free After that, it's bring your own model If you want to get started, the free tier of 3B is called Explore, and it's pretty generous. You get unlimited users, unlimited spaces, unlimited connectors, and three live workflows. The tunnel is included (and is no longer Cloudflare based) as well, so that you can connect it to your self-hosted services with ease using just a Docker container. The one exclusion is public website URLs, meaning that you can't just open a 3B-built tool to the internet at large, though anyone in your tenant can still reach it. It's more a limit on publishing rather than on building. To get you started, there's a one-time $50 AI allowance, though you can't top it up. Instead, you can bring your own model, and Tines expects most people to do exactly that using subscriptions they already pay for. That means once the $50 is used, if you're already paying for Claude or ChatGPT, then Explore keeps working indefinitely. I wanted to set it up with my local LLM, but unfortunately I couldn't get it up and running in time for this article. I'll definitely be revisiting it though to see how that fares. If you want to continue using 3B in a way where everything is hosted by Tines, though, then that's going to cost you. Tines are fairly open about 3B being an enterprise product priced accordingly, meaning that there's no route for an individual or a small team to grow into being a customer. You'll either have to live on the free plan or you'll be signing a contract, and there's no in between. Most people will likely be on the free plan forever, though given what's available, that's not such a bad place to be in. I've spent a lot of time in and around AI-related development circles, and I always found it crazy how people would develop applications with AI and deploy them without a care in the world. 3B, though, is something special, and it's the first workflow that's built end-to-end to take advantage of the strengths of AI coding while also handling the weaknesses in the best way I've seen anyone do it. If you want to get into vibe coding, it's by far the best and safest way to do it that I've seen so far.