My solve to quickly spinning up databases for rapid agentic development

I built TmpState because I kept running into the same stupid problem.

My coding agent could build most of an app. It could write the React
components, add the API route, sketch out the data model, and even tell me
what collections it wanted.

Then it needed somewhere to put data.

And that is where the flow died.

The agent would stop and I would have to go do all the human cloud stuff:

• create an account
• make a project
• provision a database
• copy an API key
• paste secrets into .env
• make sure those secrets did not get committed
• explain the connection string back to the agent

That felt wrong.

If the agent is doing the integration work, why does it need me to hand it AWS keys just to save a few JSON objects?

So I built TmpState.

TmpState is a temporary JSON database with no signup, no API keys, and no SDK.

curl https://tmpstate.dev

That returns a live database:

{
  "db": "https://tmpstate.dev/db/s-...",
  "admin": "https://tmpstate.dev/admin/s-...",
  "expires_at": "...",
  "limits": {
    "ttl_hours": 24
  }
}

The db URL is the credential.

You can write JSON to it right away:

curl -X POST "$DB/tasks" \
  -H "Content-Type: application/json" \
  -d '{"title":"ship it","done":false}'

And read it back:

curl "$DB/tasks"

That is the basic idea. One curl creates a temporary database. Normal HTTP does the rest.

No dashboard. No project setup. No account. No token. :)

Why I removed auth

I know "database with no auth" sounds like a terrible idea at first.

But for a lot of work, auth is not the problem you are trying to solve.

If you are building a weekend prototype, a hackathon demo, an AI agent scratchpad, a bug repro, or a quick internal tool, you often do not need a full production backend yet.

You need somewhere to put JSON for the next few hours.

Most database products make you pay the setup cost of a real system before you know if the idea deserves a real system.

TmpState is for the step before that.

It is not a replacement for Postgres, Supabase, Firebase, DynamoDB, or SQLite. I use those too. They are great when the project is real.

TmpState is for the moment before the project is real.

It is for when you just need the thing to run.

The URL is the key

TmpState uses capability URLs.

That means the URL itself gives access. If you have the database URL, you can read and write the database. If you do not have the URL, there is no login page and no account to guess.

This is the same basic idea as a private share link, a password reset link, or an unlisted document.

It has tradeoffs. I am not going to pretend otherwise.

You should treat the database URL like a secret. Do not put sensitive customer data in TmpState. Do not ship the URL in public frontend code for anything serious. Do not use it for regulated data.

But for temporary state, this model is really useful.

The server stores a hash of the capability token, not the raw token. The database is also temporary by default. So the whole product is built around the idea that small experiments should be easy to create and easy to clean up.

That is the security posture: private-link semantics plus expiry.

Not perfect for everything. Very good for the thing it is meant to do.

It expires becuase most prototypes should expire

Free TmpState databases live for 24 hours.

After they expire, they freeze for a short restore window before deletion. I added that because prototypes have a funny habit of becoming important right after you stop caring about them.

But deletion is still the default.

I like that.

I have too many abandoned cloud projects. Too many random test databases. Too many old API keys that probably still work somewhere.

TmpState is supposed to disappear unless you decide it should not.

If a prototype turns into something useful, you can keep it alive. There are one-time extensions starting at $1, and a Pro plan for always-on databases.

But the default path is:

1. create it
2. test the idea
3. keep it if it matters
4. let it die if it does not

That matches how I actually build my stuff.

Why this matters for AI agents

AI coding agents are basically changing who does setup work.

The agent is not just autocomplete anymore. It is becoming the integrator. It reads docs, writes glue code, tests endpoints, and carries state across a task.

But infrastructure setup is still mostly designed for humans sitting in dashboards.

That creates this awkward handoff:

1. The agent builds most of the app.
2. The agent needs persistence.
3. The human provisions infrastructure.
4. The agent waits.
5. The flow gets worse.

TmpState gives the agent a database it can create for itself.

The API is plain HTTP. The creation response includes the database URL, admin URL, limits, expiry, and docs. The site has an llms.txt file so agents can read the instructions directly.

That makes it useful as an AI agent database for:

• scratch memory during coding sessions
• test data for generated apps
• throwaway CRUD backends
• temporary webhook inboxes
• bug reproduction state
• hackathon projects
• demos
• prototypes that may or may not survive the day

The main point is not that the database is fancy.

The point is that the agent can get one without needing your cloud account.

It also works over MCP

TmpState has a remote MCP server too:

{
  "tmpstate": {
    "url": "https://tmpstate.dev/mcp"
  }
}

Add that to an MCP-compatible client and the agent can create databases and work with documents through tools instead of hand-writing curl commands.

The MCP server follows the same zero-key model. There is no OAuth step and no API token to paste.

That part actually really matters to me as a serial builder.

A lot of agent tooling still assumes a human is nearby to finish setup. I want more tools where the agent can read the docs, call the tool, persist the result, and keep going.

TmpState is my version of that for temporary JSON storage.

What TmpState is not

TmpState is not a production database for serious user data.

It does not have SQL. It does not have row-level security. It does not have realtime subscriptions. It does not have migrations. It does not have user auth. Pretty stripped down, but that was on purpose.

If your app has real users, durable data, compliance needs, or permissions, you probably want a real database. Maybe this platform can become more serious after a while.

That is fine.

TmpState is the thing before that.

It is the fastest path from "this agent needs somewhere to store JSON" to "the prototype actually runs."

And if the prototype becomes real, you can export the data and move on.

A small example

Create a database:

DB=$(curl -s https://tmpstate.dev | jq -r .db)

Create a task:

curl -X POST "$DB/tasks" \
  -H "Content-Type: application/json" \
  -d '{"title":"Write launch post","status":"draft"}'

List tasks:

curl "$DB/tasks"

Patch a task:

curl -X PATCH "$DB/tasks/doc_abc123" \
  -H "Content-Type: application/json" \
  -d '{"status":"published"}'

Delete a task:

curl -X DELETE "$DB/tasks/doc_abc123"

That is basically the whole product.

Create a temporary JSON database. Use HTTP. Let it expire when you are done.

Why I care about this

I like tools that remove a step.

Not a giant platform pitch. Not a new framework. Just one less thing between an idea and a working version of it.

TmpState is small on purpose. It is a database-shaped scratchpad for agents and builders.

The thing I want is simple: when an AI agent needs temporary state, it should not have to ask for your AWS keys.

It should just make a database and keep building.

Try it:

curl https://tmpstate.dev

Docs for humans and agents:

https://tmpstate.dev/llms.txt