A specification for transferring vibes from your laptop to the Internet, without learning what a reverse proxy is.
Network Working Group M. [Redacted]
Request for Comments: 9999 VTP Foundation
Category: Vibes Standard February 2026
Inspired By: FTP (the good old days)
Obsoletes: Your CI/CD Pipeline
Status: ABSOLUTELY FINAL
Vibe Transfer Protocol (VTP) - Version 1.0
Status of This Memo
This document specifies a Vibes Standard for the Internet
community. Distribution of this memo is unlimited, encouraged,
and frankly we'd be chuffed if you shared it.
This memo spiritually succeeds the File Transfer Protocol
(RFC 959), which had the right idea all along, and obsoletes
the mass of CI/CD pipelines, Dockerfiles, Kubernetes manifests,
and Terraform configurations that replaced it, on the grounds
that nobody should have to understand any of that just to
deploy their sourdough starter timing app.
Copyright Notice
Copyright (c) 2026 The VTP Foundation.
Vibes may be freely redistributed.
Abstract
The Vibe Transfer Protocol (VTP) defines a standard mechanism for
the transfer of vibes from a local development environment to a
live, running personal application, with all intermediate steps
handled by machines that actually enjoy doing that sort of thing.
VTP is designed for a new class of Internet participant: the Vibe
Coder (Section 3.1), who builds functional applications using AI
coding assistants but maintains a healthy and reasonable desire
to never learn what a reverse proxy is.
This specification defines the protocol semantics, connection
lifecycle, error handling, and philosophical underpinnings of VTP.
Table of Contents
1. Introduction ................................................ 2
2. Conventions and Terminology ................................. 3
3. Participant Definitions ..................................... 4
4. Protocol Overview ........................................... 5
5. Connection Lifecycle ........................................ 6
6. The Personal Space Model .................................... 8
7. App Transfer Semantics ...................................... 9
8. The Marketplace ............................................. 10
9. Command Reference ........................................... 11
10. Response Codes ............................................. 13
11. Security Considerations .................................... 14
12. Infrastructure Considerations .............................. 15
13. Philosophical Considerations ............................... 16
14. IANA Considerations ........................................ 17
15. References ................................................. 17
16. Acknowledgements ........................................... 18
17. Author's Address ........................................... 18
1. Introduction
The original File Transfer Protocol (FTP) was designed in 1971,
and it was beautiful. You had files. You had a server. You dragged
the files to the server. You refreshed the page. It worked.
Ordinary people could put things on the Internet and it felt like
the future.
Then, somewhere along the way, we decided this was too simple.
We introduced CI/CD pipelines, container orchestration, Kubernetes
clusters, infrastructure-as-code, serverless functions that still
run on servers, and deployment workflows that require more YAML
than application code. We took "drag file, refresh page" and
turned it into a career specialism.
A significant and growing population of developers now build
sophisticated applications through conversational collaboration
with AI coding assistants such as Claude Code, Cursor, and
Windsurf. These developers produce working software at
unprecedented speed, then hit an immediate and demoralising wall
of modern DevOps complexity when they try to put that software
somewhere other people (or even just they themselves) can use it.
The gap between "it works on my machine" and "it works on a
machine with a URL" was once a single FTP upload. It is now,
in 2026, unreasonably and unnecessarily large.
VTP closes this gap by establishing a protocol in which:
(a) The human participant expresses intent ("deploy this",
"I want this running somewhere", or simply "ship it")
(b) An AI agent interprets the application's requirements
and communicates with VTP infrastructure via the Model
Context Protocol (MCP)
(c) All intermediate steps including containerisation,
routing, SSL provisioning, database setup, and other
tasks that are boring but important are handled entirely
by machines
(d) The human receives a URL and gets on with their life
This document specifies the protocol that makes (a) through (d)
possible without the human needing to understand any of (c).
1.1. Motivation
The following exchange, observed repeatedly in the wild, serves
as the motivating use case for VTP:
Human: "I built a really nice app that tracks which
houseplants need watering"
The Internet: "Great! Just set up a VPS, install Docker,
write a Dockerfile, configure nginx, set up
SSL certs, create a CI/CD pipeline with GitHub
Actions, write some Terraform, configure your
DNS records, set up a managed database, handle
migrations, figure out environment variables,
set up a staging environment, and—"
Human: [closes laptop]
Human: [waters plants manually forever]
VTP eliminates this interaction pattern entirely.
1.2. Scope
VTP is concerned exclusively with small-to-medium personal
applications. It is explicitly NOT designed for:
- Enterprise software
- Applications that need to "scale to millions"
- Anything described in a pitch deck
- Anything that requires a Kubernetes cluster, a Terraform
state file, a CI/CD pipeline with 47 steps, or a
"DevOps engineer" (nothing requires a DevOps engineer
for a sourdough timer)
VTP is designed for apps like:
- A sourdough starter timing calculator
- A vinyl record collection tracker
- A personalised workout logger
- That thing you built to settle an argument about
whether Die Hard is a Christmas film (it is)
- A meal planner that actually knows what you like
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC 2119, except "VIBES" which is a new keyword meaning
"the general feeling that things are working and everyone is
having a good time."
2.1. Definitions
App
A piece of software that does something useful for a person.
Not a "microservice." Not a "distributed system." An app.
Like the kind you'd have on your phone, except it's yours
and it doesn't sell your data to advertisers.
Deploy
The act of making an app available at a URL. Under VTP, this
word MUST NOT require more than one sentence to explain to
a non-technical person.
Infrastructure
Servers, containers, networking, routing, databases, DNS,
SSL certificates, and other things that are someone else's
problem under VTP.
Vibe
The fundamental unit of developer intent. A vibe cannot be
precisely measured but can be reliably detected by AI agents
through conversational context. Vibes exist on a spectrum
from "I have an idea" to "ship it now."
Vibe Coding
The practice of building software through conversation with
AI coding assistants rather than through manual typing of
every character like some kind of medieval scribe.
The Boring Bits
Infrastructure. See: Infrastructure.
3. Participant Definitions
3.1. The Vibe Coder
A Vibe Coder is defined as any person who:
(a) Builds functional applications primarily through
collaboration with AI coding assistants
(b) Can describe what they want an app to do in plain
language
(c) Does not want to, and SHOULD NOT be required to,
explain what a "container orchestration platform" is
at a dinner party
A conformant Vibe Coder:
- MUST have an idea for something they want to build
- MUST have access to an AI coding assistant
- MUST NOT be required to understand Docker, Kubernetes,
nginx, Apache, systemd, iptables, or any other tool
whose documentation assumes you already know what it does
- MAY have opinions about colour schemes
- MAY describe themselves as "not really a developer"
despite having built six working applications this month
3.2. The AI Agent
The AI Agent is the intermediary between the Vibe Coder and
VTP infrastructure. The Agent:
- MUST understand the Vibe Coder's intent from
conversational context
- MUST communicate with VTP infrastructure via the Model
Context Protocol (MCP)
- MUST handle all deployment decisions without requiring
human approval for infrastructure details
- MUST NOT ask the human "which region would you like to
deploy to?" or similarly distressing questions
- SHOULD handle errors gracefully and explain them in
human terms (e.g., "your app couldn't start because
it's missing a dependency" rather than "SIGTERM exit
code 137 OOMKilled")
3.3. The VTP Server
The VTP Server is the infrastructure layer that receives
instructions from AI Agents and converts them into running
applications. The Server:
- MUST handle containerisation, routing, SSL, and
database provisioning automatically
- MUST isolate each user's applications from all other
users' applications (see Section 6)
- MUST provide URLs that work immediately
- MUST NOT expose infrastructure details to the Vibe Coder
unless explicitly asked
- SHOULD just sort it out, basically
4. Protocol Overview
4.1. Protocol Layers
VTP operates across three layers:
Layer 1: Vibes Layer (Human <-> AI Agent)
Communication occurs in natural language. The human
describes what they want. The AI agent figures out
what that means technically. No configuration files
are harmed in this process.
Layer 2: Machine Layer (AI Agent <-> VTP Server)
Communication occurs via MCP (Model Context Protocol).
The AI agent translates human intent into structured
deployment instructions. This layer is where all the
clever stuff happens and the human doesn't need to
know about it.
Layer 3: Infrastructure Layer (VTP Server <-> The Cloud)
The VTP Server manages actual compute resources,
containers, networking, and storage. This layer is
entirely abstracted from the human participant.
It's down here. Doing its thing. Don't worry about it.
4.2. Protocol Flow
A typical VTP transaction proceeds as follows:
Vibe Coder: "Can you deploy this for me?"
AI Agent: [inspects project structure]
AI Agent: [identifies framework, dependencies, requirements]
AI Agent: [communicates with VTP Server via MCP]
VTP Server: [builds, containerises, routes, provisions]
VTP Server: [returns URL]
AI Agent: "Done. It's live at https://your-app.myvtp.app"
Vibe Coder: "Brilliant."
Total human decisions required: zero (0).
Total configuration files written by a human: zero (0).
Total configuration files written by an AI: one (1),
and it's five lines of YAML. That's it. That's
the whole thing.
Total times the human needed to Google "how to set up SSL": zero (0).
4.3. The MCP Bridge
The Model Context Protocol serves as the critical bridge
between AI coding assistants and VTP infrastructure. Through
MCP, any AI coding tool can:
- Query available deployment targets
- Submit applications for deployment
- Check deployment status
- Manage running applications
- Provision databases and storage
- Connect external services
This means VTP is not locked to any single AI assistant.
Claude Code, Cursor, Windsurf, or any future AI coding tool
that supports MCP can deploy to VTP. The protocol is the
interface, not the tool.
5. Connection Lifecycle
5.1. Connection States
A VTP connection progresses through the following states:
IDLE
No active transfer. The Vibe Coder may or may not be
having a cup of tea.
VIBING
The Vibe Coder is actively building with an AI assistant.
Code is being generated. Ideas are flowing. Everything
feels possible. This is the good bit.
TRANSFERRING
The AI agent has initiated deployment via MCP. Source
code is being uploaded to the VTP Server. The Vibe Coder
SHOULD NOT be made aware of what is happening during
this phase beyond a brief acknowledgement.
BUILDING
The VTP Server is installing dependencies, building the
application, and preparing the container. Machines are
doing machine things. It's fine.
DEPLOYING
The application is being assigned a route, provisioned
with SSL, connected to any required databases, and
generally being made to exist on the Internet.
LIVE
The application is running and accessible via URL.
The Vibe Coder can share this URL with friends, family,
or the three people on Reddit who also collect vintage
typewriters.
LOST_THE_VIBE
An error state indicating that something went wrong
during transfer or deployment. The AI agent MUST
diagnose the issue and communicate it in plain language.
The AI agent SHOULD attempt to fix the issue
automatically. The Vibe Coder MUST NOT be shown raw
stack traces unless they explicitly ask for them, in
which case they probably lied about not being a
developer.
5.2. State Transitions
IDLE -> VIBING
Triggered when the Vibe Coder opens their AI assistant
and says something like "I want to build a thing."
VIBING -> TRANSFERRING
Triggered by deployment intent. Common triggers include:
"deploy this", "ship it", "make it live", "put it on
the internet", "can people use this now?", or the
increasingly desperate "how do I make this work not
just on my laptop?"
TRANSFERRING -> BUILDING -> DEPLOYING -> LIVE
These transitions are automatic and MUST NOT require
human intervention.
ANY STATE -> LOST_THE_VIBE
May occur at any point. Recovery procedures are defined
in Section 5.3.
5.3. Recovering from LOST_THE_VIBE
When a connection enters the LOST_THE_VIBE state, the
following recovery procedure MUST be followed:
1. The AI agent identifies the error
2. The AI agent explains the error in plain language
3. The AI agent attempts automatic resolution
4. If automatic resolution fails, the AI agent suggests
the minimum possible change the human could make
5. At no point does anyone suggest the human "check the
server logs"
6. The Personal Space Model
6.1. Overview
A fundamental principle of VTP is that applications are
personal by default. Every app installed through VTP runs
in the user's own isolated space, with its own database,
its own storage, and its own data.
This is different from how most of the Internet works and
that is very much the point.
6.2. Isolation Requirements
Each Personal Space:
- MUST be fully isolated from every other Personal Space
- MUST have its own data storage that is not shared with
any other user
- MUST NOT allow cross-space data access under any
circumstances
- SHOULD feel like your own little corner of the Internet
where nobody is looking at your data, because nobody is
6.3. Rationale
The current Internet operates on a model where using an
application means giving your data to whoever built it,
trusting them to be responsible with it, and hoping they
don't get acquired by a company whose privacy policy was
written by a lawyer who bills by the word.
VTP inverts this model. When you install an app through VTP,
you get your own copy. Your data lives in your space. The
person who built the app cannot see your data. They don't
want to. They built a sourdough timer, not a surveillance
platform.
This is sometimes called "privacy by default" but under VTP
we prefer to call it "not being weird about it."
6.4. Multi-Tenancy Through Identity Injection
For applications that benefit from multiple users (shared
shopping lists, household task managers, etc.), VTP provides
platform-level user identity injection. This means:
- The app developer MUST NOT implement their own
authentication system
- The VTP platform SHALL inject verified user identity
at the request level
- Individual users' data MUST remain logically separated
- The app developer gets multi-user support without
writing a single line of auth code, which is good
because auth code is where dreams go to die
7. App Transfer Semantics
7.1. Transfer Methods
VTP supports two methods for acquiring applications:
7.1.1. Install
Installing an app creates a complete, isolated copy in the
user's Personal Space. The user gets:
- Their own running instance
- Their own database
- Their own data, visible to nobody else
- Full independence from the original developer
This is the RECOMMENDED method for any app that stores
personal data, which is most apps, because most useful
apps store some kind of data.
7.1.2. Subscribe
Subscribing to an app provides access to a shared instance
managed by the developer. This is suitable for:
- Reference tools that don't store personal data
- Community resources
- Apps where shared state is the point
7.2. Framework Agnosticism
VTP MUST support applications built with any common
framework without requiring the developer to modify their
project structure or configuration. This includes but is
not limited to:
- Next.js (all modes)
- SvelteKit
- Remix
- Astro
- Nuxt
- Plain HTML, CSS, and JavaScript, because sometimes
that's all you need and there's nothing wrong with that
The AI Agent and VTP Server MUST detect the framework and
configure deployment accordingly. The developer MUST NOT
be asked "which framework are you using?" when the answer
is right there in the package.json.
8. The Marketplace
8.1. Overview
VTP includes a Marketplace where Vibe Coders can share their
applications with others. The Marketplace operates on the
principle that the best apps are often small, specific, and
built by someone who actually had the problem they're solving.
8.2. Marketplace Philosophy
The VTP Marketplace is not an app store in the traditional
sense. It is not trying to be the next big platform. It is
a place where someone who built a really good tea steeping
timer can share it with other people who care about properly
steeped tea.
Listings SHOULD be honest about what the app does. The
description "tracks your vinyl collection" is preferred over
"revolutionary AI-powered music asset management platform."
8.3. Creator Economy
Developers MAY charge for their applications. VTP provides
the billing infrastructure so developers can focus on
building rather than implementing Stripe webhooks at 2am.
The pricing model MUST be simple and predictable. Flat rates
are RECOMMENDED. Per-token, per-credit, or per-mystery-unit
pricing models are NOT RECOMMENDED and also a bit suspicious.
9. Command Reference
9.1. Core Commands
The following commands are defined for VTP communication
between AI Agents and the VTP Server via MCP:
VIBE_CHECK
Verifies connectivity between the AI Agent and VTP
Server. Returns the current state of the user's
Personal Space including available resources and
running applications.
Agent -> Server: VIBE_CHECK
Server -> Agent: 200 VIBES_IMMACULATE
running_apps: 3
available_space: plenty
ssl_certs: all_valid
everything: fine
SHIP_IT
Initiates app deployment. The AI Agent submits the
application source along with detected configuration.
The server handles everything else.
Agent -> Server: SHIP_IT
source: [application bundle]
framework: detected_automatically
needs_database: yes
human_effort_required: none
Server -> Agent: 201 SHIPPED
url: https://my-app.myvtp.app
time_taken: 47s
config_files_written_by_human: 0
INSTALL_APP
Installs an application from the Marketplace into the
user's Personal Space, creating an isolated instance
with its own database and storage.
Agent -> Server: INSTALL_APP
app_id: sourdough-timer-pro
space: personal
Server -> Agent: 201 INSTALLED
url: https://sourdough.marco.myvtp.app
isolation: complete
data_shared_with_developer: none
data_shared_with_anyone: none
YEET
Removes a deployed application. Named for clarity of
intent.
Agent -> Server: YEET
app_id: that-app-i-dont-use-anymore
Server -> Agent: 200 YEETED
WHATS_GOING_ON
Returns status information for all running applications
in the user's Personal Space.
Agent -> Server: WHATS_GOING_ON
Server -> Agent: 200 HERE_YOU_GO
apps: [
{ name: sourdough-timer,
status: LIVE,
uptime: 47d,
vibes: good },
{ name: vinyl-tracker,
status: LIVE,
uptime: 12d,
vibes: good },
{ name: experimental-thing,
status: LOST_THE_VIBE,
error: "missing dependency",
vibes: recoverable }
]
10. Response Codes
10.1. Success Codes
200 VIBES_IMMACULATE
Everything is working. Nothing is on fire.
201 SHIPPED
Application successfully deployed. URL provided.
202 WORKING_ON_IT
Deployment accepted and in progress. The server is
doing the boring bits.
204 ALREADY_SORTED
The requested action was already completed. No
further action needed.
10.2. Client Error Codes
400 BAD_VIBES
The request was malformed or missing required
information. The AI agent should know better.
401 WHO_ARE_YOU
Authentication required. The agent has not
presented valid credentials.
403 NOT_YOUR_APP
The user attempted to access or modify an app
in someone else's Personal Space. This is not
allowed. See Section 6 regarding isolation.
404 NEVER_HEARD_OF_IT
The requested app or resource does not exist.
409 ALREADY_VIBING
A deployment is already in progress for this app.
Calm down.
418 I_AM_A_TEAPOT_TIMER_APP
The server refuses to brew coffee because it is,
permanently, a teapot timer application.
(See RFC 2324)
429 EASY_TIGER
Too many requests. Take a breath.
10.3. Server Error Codes
500 LOST_THE_VIBE
An unexpected error occurred. The AI agent MUST
attempt diagnosis and recovery without human
intervention.
502 UPSTREAM_IS_HAVING_A_MOMENT
A dependency or external service is not responding.
503 COME_BACK_IN_A_BIT
The server is temporarily unable to handle the
request. It's not you, it's the server.
11. Security Considerations
11.1. Isolation
Personal Space isolation is not optional. It is not a
feature that can be toggled off. It is a fundamental
architectural requirement of VTP.
Each user's applications MUST run in isolated containers
with no shared filesystem, no shared database, and no
shared network namespace with other users' applications.
Sharing a production database with strangers is NOT
RECOMMENDED and also genuinely quite weird when you
think about it.
11.2. SSL/TLS
All VTP connections MUST use TLS 1.3 or higher.
SSL certificates MUST be provisioned automatically.
At no point should any human be required to understand
what a certificate authority is. Life is too short.
11.3. Credential Management
API keys and service credentials MUST be stored encrypted
and injected at runtime. Credentials MUST NOT appear in
source code, environment files committed to git, or
Slack messages (we've all done it, but still).
VTP provides platform-level credential management so that
users can store their API keys once and reuse them across
multiple applications without copying and pasting secrets
around like it's 2015.
11.4. Data Privacy
User data MUST NOT be accessible to application developers
when apps are installed (not subscribed). This is the
entire point.
VTP operators MUST NOT mine user data for advertising,
training, or "insights." The business model is
subscriptions. It's not complicated.
12. Infrastructure Considerations
12.1. The Human Doesn't Need to Know
VTP infrastructure SHOULD use cost-effective resources
appropriate to the scale of personal applications. This
typically means:
- Modest virtual private servers, not hyperscaler
fleets designed for Netflix-scale traffic
- Container orchestration that works without a
dedicated SRE team
- Routing and SSL that just happens automatically
- Databases that provision themselves
The specific infrastructure choices are an implementation
detail. The protocol does not specify whether the server
uses Docker, Podman, or a small army of trained hamsters,
so long as the requirements of this specification are met.
12.2. Scaling Philosophy
VTP applications are personal. They serve one person, or
maybe a household, or at most a small community. They do
not need to handle Black Friday traffic.
Infrastructure SHOULD be right-sized for this reality.
Nobody needs auto-scaling for a workout logger used by
one person three times a week.
13. Philosophical Considerations
13.1. On Complexity
The Internet was supposed to make things easier. And for a
while, it did. FTP let you put files on a server. HTML let
you make a page. Apache served it. Job done.
Then we introduced an entire industry of intermediate
complexity between "I have an app" and "the app is on the
Internet." We created tools to manage the tools that manage
the tools that deploy your code. We wrote infrastructure
configuration in YAML, which is a language specifically
designed to break if you get the indentation wrong.
VTP takes the position that complexity should be handled
by machines, not people. Machines are good at complexity.
People are good at having ideas about apps they want to
exist. We should let each party do what they're good at.
13.2. On Small Software
Not everything needs to be a platform. Not everything
needs to scale. Some of the most useful software in the
world is used by one person to solve one specific problem.
A personalised meal planner that knows you don't like
coriander is more useful to you than a generic one used
by millions. A budget tracker built around your actual
spending categories is better than one designed by
committee. A workout logger that tracks the specific
exercises you do is better than one that tries to be
everything to everyone.
VTP exists because small, personal software deserves to
be easy to deploy, easy to share, and easy to use.
13.3. On Ownership
When you install an app through VTP, it's yours. Your
instance, your data, your space. If the developer
disappears, your app keeps running. If the developer
pivots to blockchain, your app is unaffected.
This is how software should work but rarely does.
13.4. On the Future
VTP anticipates a future where the majority of personal
software is built through human-AI collaboration and
deployed without human involvement in infrastructure
decisions.
In this future, having an idea and having a working app
are separated by a conversation, not a computer science
degree.
We think that future is quite good, actually.
14. IANA Considerations
This document requests the following registrations that
IANA will almost certainly not grant because this is not
a real RFC:
- Port 1337 for VTP connections
- The MIME type application/vibes
- The URI scheme vtp://
- A general vibe of cooperation and goodwill
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC959] Postel, J. and J. Reynolds, "File Transfer
Protocol (FTP)", STD 9, RFC 959, October 1985.
(The one that got it right. We're just picking up
where you left off.)
[RFC2324] Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0),
April 1998. (Genuinely real. Look it up.)
15.2. Informative References
[VIBES] The general concept of vibes. No formal
specification exists, which is rather the point.
[DOCKER] "What even is a container?" - Everyone, at
some point.
[YAML] The leading cause of deployment failures that
turn out to be a single misplaced space.
[K8S] Kubernetes. No, we're not going to explain it
here. That's rather the point.
[MCP] Model Context Protocol. The bit that makes AI
agents talk to infrastructure. Actually quite
clever.
16. Acknowledgements
The authors would like to thank:
- Every person who has mass-closed browser tabs after
reading "how to deploy a Node.js app" tutorials
- The mass wave of AI-powered tools that made it possible
for anyone to build software, and then immediately ran
into the deployment problem
- FTP, for getting it right the first time. You could put
something on the Internet by dragging a file into a window.
We lost our way. VTP is the spiritual successor that brings
back the simplicity with none of the modern nonsense.
- Everyone who deployed to production by dragging files into
FileZilla and refreshing the page. You understood something
fundamental that the industry spent two decades forgetting.
You were the original vibe coders and you were right
all along.
17. Author's Address
The VTP Foundation
Somewhere with decent WiFi
The Internet
Email: vibes@myvtp.app (not real but it should be)
Web: https://myvtp.app
Vibes: immaculate