Launching today
fline
Your agent ships the repo. We build it and run it.
8 followers
Your agent ships the repo. We build it and run it.
8 followers
Connect your coding agent over MCP and it ships your repo. fline writes the Dockerfile and the compose, picks the ports, provisions managed Postgres or Valkey, and hands back a URL already serving. The work happens outside your agent's context, so the deploy does not eat the session you were using to build. Secret values never pass through the agent: it declares the variable names, gets a link, and hands it to you unopened. Private beta, one node, and a maintained list of what does not work.
Hello Hunters, I'm Vlad, a solo developer of Fline
I ask my agent to deploy something and it starts writing a Dockerfile. Then it picks a port, guesses a compose file, invents a health check, and spends a few thousand tokens of the context I was using for the application on infrastructure it will get subtly wrong — the wrong base image, a port nothing is listening on, a database URL assembled from three variables that do not exist yet. It usually gets there. The cost is that the session is now half infrastructure.
The direct ancestor of this is a project called hoster, which gave every git branch its own live environment: CI pushed an image and made one HTTP call, and a few seconds later that branch was serving. It worked because the caller was a pipeline. What changed my approach was realising that once the caller is a model holding a conversation, every constraint inverts. Context becomes the scarce resource. The manifest becomes untrusted input. The human stops being the operator and becomes the exception.
So the work moves off the agent. Your agent uploads the archive straight to object storage, so the code never enters its context. The platform reads a distillate, works out how the project builds, and writes the Dockerfile and the compose — the one in your repository is not the one that runs. Managed Postgres or Valkey is provisioned and the connection string written in for you. No port is typed anywhere: PORT is injected and whatever the process opens is routed. Commit the returned smartline.json and later deploys make no planning call at all.
One step is yours and stays yours. Your agent declares the names of the environment variables it found and asks for a link. It hands you the link and does not open it; you type the values in a browser. That is not a policy I am asking you to take on trust — no MCP scope carries an environment value, and none can be added that would.
What does not work, by name. No billing, no metering, no pricing. No teams and no roles: one identity, one personal tenant. No CLI and no SDK, because your agent is the client. It never builds from git; the input is always an archive, deliberately. Logs are a bounded tail, not storage or search. It runs on one node, and roughly fifty new projects a week can get a certificate, which is why there is a waitlist rather than a signup button.
The most useful thing I did preparing this launch was audit the eight capabilities the page claimed. Three did not survive: rollback, tenant-visible traces, and quota coverage were all real, working code that no customer could actually reach. They are on the not-yet list now, which is eleven items long.