tldr: automated git repos. yknow, like normal git but for AI, bro
pksunkara•Feb 14, 2026
I am still curious why they stopped offering their original service. What was the feedback from users? Why did developers not want to use it?
wahnfrieden•Feb 14, 2026
probably ai became the bigger opportunity
fat•Feb 14, 2026
Ahh good question…
Here's the timeline if you're interested.
3 years ago we started building a direct competitor to GitHub with the theory that you need to build code storage, code review and CI to truly compete.
We spent about a year prototyping this all out, raised some money, and then started building this for real [tm].
Code storage felt like a HUGE moat for GitHub. Most of our competitors in the code review space:
- graphite
- linear
- (now cognition)
- etc
All built directly on GitHub's apis – but we wanted to go down to the metal (something wrong with us).
A year and half into doing this, a few folks reached out and asked how we were scaling git… i waved my hands around a bunch and explained how hard of a distributed systems problem scaling git was… explained git three-phase commits, etc.
Fast forward a few more months, and we started standing up single tenant clusters of our infra for a few different codegen companies that also needed storage solutions.
And now here we are :)
leohonexus•Feb 14, 2026
I have a suspicion most of these types of agent-targeted SaaS will die out once the human equivalents implement their agent layers / MCPs.
Agents having no way to pay for their use is one thing; lack of deep integration within the business domain is another (e.g. if you're a Git provider, you'd probably want to offer CI/CD, PR workflows, release management, publicly discoverable repos etc., and boom - you just copied GitHub)
thomasjb•Feb 14, 2026
There's probably still going to be a box of hard drives in a datacenter somewhere, it does make sense to have a layer to manage the agent interface, rather than letting agents completely loose on all your storage.
leohonexus•Feb 14, 2026
Agreed, but I'm making a distinction between the platform (whether it be Cloudflare Moltworker or a Mac Mini), which a human chooses for the agent to run on (for now), and tools designed to be discovered and consumed by the agents themselves (e.g. code.storage, AgentMail).
fat•Feb 14, 2026
We're actually meant to be less of a consumer product than i think you mean by this (but i may have misunderstood).
We're more targeting enterprise as storage infrastructure provider – selling directly to platforms who generate a bunch of code and need a place to put it.
end users wont really know we exist.
abluecloud•Feb 14, 2026
maybe i'm too stupid but i dont have a clue what this is
wahnfrieden•Feb 14, 2026
low friction github repos for massively parallelized agentic use. which may also be ephemeral.
fat•Feb 14, 2026
pretty much - low friction git* repos for massively parallelized agentic use.
(can think of it kinda like what stripe does for payments… headless git infra, where you get an api key, and store / create as many repos as your customers need).
brandonmenc•Feb 14, 2026
It's hard for me to trust a site that looks like a cryptic design portfolio from the early 2000s.
jackfischer•Feb 14, 2026
Why is that? Personally I appreciated the throwback look and it probably accomplished its goal of being memorable. Turbopuffer is another notable one seemingly leaning into this flavor of marketing
verdverm•Feb 14, 2026
It doesn't look professional in the sense of a mature business
there are numerous inconsistencies and broken links
The link text that says they raised $23M but doesn't go anywhere is real sus
ares623•Feb 14, 2026
tbh I find it a 100x better than the current Tailwind monoculture where every site looks like it's shilling a crypto coin
neom•Feb 14, 2026
Keep trying to sign up and get "Whoops, this email isn't allowed access. Try again." :( working for anyone else?
fat•Feb 14, 2026
not open access yet, sorry :(
neom•Feb 14, 2026
sadge, thoughts on when live? This is very good idea I can even imagine right now how good it could feel, if it's what I expect, that will be very good.
fat•Feb 14, 2026
planning to share more in the next month or so :)
But have been slowly signing folks up – if you want to shoot me an email, can get you setup jacob@pierre.co
hollow-moe•Feb 14, 2026
"git init --bare" as a service what a time to be alive
pphysch•Feb 14, 2026
And it only costs $30K per year for a single terabyte of usable (NVMe?) storage. The value!
$1 GiB/month x 3 minimum replicas x 1024 GiB x 12 months
And according to the status page they only have CDNs in us-east and eu-central.
cyanydeez•Feb 14, 2026
If youre not fishing for AI backed VC tricklnomics, do you even deserve to call yourself a programmer
verdverm•Feb 14, 2026
Did you happen to look at OPs prices?
They are a no way for me, especially the network fees
nusl•Feb 14, 2026
It's basically hosted Git infrastructure as an API service, aimed at AI coding platforms rather than human developers.
Took me a really long time to understand this. The blob thing is cool but otherwise it's a really confusing website. The audio playing without me wanting it was not cool though.
fat•Feb 14, 2026
thanks for the feedback – we definitely have work to do on communicating what we're up to.
Sorry about the audio - will get that patched
Bnjoroge•Feb 14, 2026
iirc like they pivoted from being a github replacement with their own vcs
fat•Feb 14, 2026
Hey everyone,
Wow, you scooped us! we weren’t really expecting to launch here just yet, but happy to answer any questions y’all have :)
First, Pierre is building code storage for machines -- think GitHub’s infrastructure layer, but API-first and tuned for LLMs.
What does that actually mean? We’ve spent the last 18+ months speed running GitHubs infrastructure (with a lot of help from early GitHub folks)… this is Github’s spoke architecture with a few modern twists + object store for cold storage.
Up until this point, GitHub is the only team that’s built a truly scalable git cluster (gitlab, bitbucket, etc. are all enterprise plays, with different tradeoffs).
Code.Storage is meant to be massively scalable… and we’ll be doing a larger post on what that means, and the scale we’re already doing soon hopefully :)
On top of this, we’ve invested a TON of time into our API layer – we have all the things you’d expect, list files, create branch, commit, etc. – with some new api’s that agents have found helpful: grep, glob based archive, ephemeral branches (git namespaces), etc.
Right now we’re in private beta – but happy to do my best to answer any questions in the short term (and if you’re working on anything that might benefit from code storage or storing code like artifacts – please reach out to jacob@pierre.co
a11r•Feb 14, 2026
It would be nice to see a side-by-side comparison with Github on pricing and features. We are using github and creating hundreds of repos everyday without any issues (except for the occassional API outages that Github has). Curious to see your take on where Pierre is better.
fat•Feb 14, 2026
To be fair to GitHub (which i have a lot of love and respect for), we're building very different products.
GitHub is a social consumer coding product first. There's user models, review and discussion primitives, ci, etc.
Code Storage is just a headless, api-first infra product. No users, no review primitives, no rate limits, etc.
Our company is obsessively focused on only 3 things:
1. reliability at scale
2. performance
3. code api surface
happy to dive into any of these in more detail if you want to shoot me over an email jacob@pierre.co
a11r•Feb 14, 2026
Understood. I am looking for a side-by-side comparison focused on your feature set, not Github's. You answered it partially by calling out your focus areas. Github API reliability has been iffy for us, so it would be good to quantify the difference we can expect to get with you.
fat•Feb 14, 2026
Sure – our API is built specifically for common LLM workflows. Here's a great example.
LLMs are often used for changing code. If an LLM creates a patch that touches 10 files, you need to take the following steps to save that patchfile on GitHub using their rest API.
.
1. Get the base branch SHA
2. Create a new branch (ref)
3. Create blobs (one per file… 10 blobs!)
4. Create a tree containing those 10 file changes
5. Create a commit
6. Update the branch ref to point to the new commit
7. Pull the GitHub api until it stops returning 422's (an eventual consistency issue when GitHub is under high load)
.
About 15 total requests…
With code.storage you just post the complete diff:
On top of ergonomics, we have first class APIs for git notes, grep, get archive (include/exclude by blob), and other filesystem behavior that is exceeding helpful when working with LLMs.
verdverm•Feb 14, 2026
The prices are ridiculous imo, charging for network ingress is a full stop
I've been look for a way to use Git for smaller, high volume document storage - think something like Google docs where every doc is a repo and every change is a commit - but also, where the vast majority of docs age out and are effectively archived and not used, but still need to be available.
This looks like it technically, I just wonder how well the pricing scales for that case of docs that might never be read again...
imownbey•Feb 14, 2026
For cost we put repositories into cold storage once they are not read for a week. This helps long term costs stay pretty minimal. You can also delete repositories via the API if you’d prefer.
fat•Feb 14, 2026
Git is ~ really ~ great at document storage :P
We have folks using us to back crms, design tools, and all kinds of "non-code" stuff.
Please reach out - would love to connect!
bluerooibos•Feb 14, 2026
So what benefit does the API layer give over just being able to use git directly?
And agreed with other commenters about better explaining what this is - some examples and use cases side by side with the alternatives would work.
adithyassekhar•Feb 14, 2026
Intersting concept. I just can't get my mind off one of the blurbs from the page
>Code Storage is designed for modern workloads: Vibe Coding platforms generating 1m+ new repos a day, AI copilots writing thousands of commits per session, teams branching and merging in real time, and apps syncing code across devices.
This is sort of a rant, skip if you must
Those 1m+ repos all have code no human has ever seen or will see. I'm afraid of being a luddite. But I can't believe we're taking vibe coding seriously, especially with these enterprise SaaS startups aimed at it. Abstractions have always come up but this is knowledge handover, this is knowledge reduction or destruction.
What happens to all of humanities greatest inventions when the current generation of developers die out? Who's going to maintain the basement? Where things haven't been abstracted? Who's learning at that level, who's keeping the knowledge alive when everyone's being told you just need to vibe instead of thinking logically?
I know why the push, people who never wanted to be developers, people who never wanted to code got into this for a paycheck or something else, they're welcoming this with both hands. I've seen people slowly lose their abilities they tried so hard to make.
I'm being fricking dramatic here all because of that blurb.
12 Comments
Here's the timeline if you're interested.
3 years ago we started building a direct competitor to GitHub with the theory that you need to build code storage, code review and CI to truly compete.
We spent about a year prototyping this all out, raised some money, and then started building this for real [tm].
Code storage felt like a HUGE moat for GitHub. Most of our competitors in the code review space:
- graphite - linear - (now cognition) - etc
All built directly on GitHub's apis – but we wanted to go down to the metal (something wrong with us).
A year and half into doing this, a few folks reached out and asked how we were scaling git… i waved my hands around a bunch and explained how hard of a distributed systems problem scaling git was… explained git three-phase commits, etc.
Fast forward a few more months, and we started standing up single tenant clusters of our infra for a few different codegen companies that also needed storage solutions.
And now here we are :)
Agents having no way to pay for their use is one thing; lack of deep integration within the business domain is another (e.g. if you're a Git provider, you'd probably want to offer CI/CD, PR workflows, release management, publicly discoverable repos etc., and boom - you just copied GitHub)
We're more targeting enterprise as storage infrastructure provider – selling directly to platforms who generate a bunch of code and need a place to put it.
end users wont really know we exist.
(can think of it kinda like what stripe does for payments… headless git infra, where you get an api key, and store / create as many repos as your customers need).
there are numerous inconsistencies and broken links
The link text that says they raised $23M but doesn't go anywhere is real sus
But have been slowly signing folks up – if you want to shoot me an email, can get you setup jacob@pierre.co
$1 GiB/month x 3 minimum replicas x 1024 GiB x 12 months
And according to the status page they only have CDNs in us-east and eu-central.
They are a no way for me, especially the network fees
Took me a really long time to understand this. The blob thing is cool but otherwise it's a really confusing website. The audio playing without me wanting it was not cool though.
Sorry about the audio - will get that patched
Wow, you scooped us! we weren’t really expecting to launch here just yet, but happy to answer any questions y’all have :)
First, Pierre is building code storage for machines -- think GitHub’s infrastructure layer, but API-first and tuned for LLMs.
What does that actually mean? We’ve spent the last 18+ months speed running GitHubs infrastructure (with a lot of help from early GitHub folks)… this is Github’s spoke architecture with a few modern twists + object store for cold storage.
Up until this point, GitHub is the only team that’s built a truly scalable git cluster (gitlab, bitbucket, etc. are all enterprise plays, with different tradeoffs).
Code.Storage is meant to be massively scalable… and we’ll be doing a larger post on what that means, and the scale we’re already doing soon hopefully :)
On top of this, we’ve invested a TON of time into our API layer – we have all the things you’d expect, list files, create branch, commit, etc. – with some new api’s that agents have found helpful: grep, glob based archive, ephemeral branches (git namespaces), etc.
Right now we’re in private beta – but happy to do my best to answer any questions in the short term (and if you’re working on anything that might benefit from code storage or storing code like artifacts – please reach out to jacob@pierre.co
GitHub is a social consumer coding product first. There's user models, review and discussion primitives, ci, etc.
Code Storage is just a headless, api-first infra product. No users, no review primitives, no rate limits, etc.
Our company is obsessively focused on only 3 things:
1. reliability at scale 2. performance 3. code api surface
happy to dive into any of these in more detail if you want to shoot me over an email jacob@pierre.co
LLMs are often used for changing code. If an LLM creates a patch that touches 10 files, you need to take the following steps to save that patchfile on GitHub using their rest API.
.
1. Get the base branch SHA
2. Create a new branch (ref)
3. Create blobs (one per file… 10 blobs!)
4. Create a tree containing those 10 file changes
5. Create a commit
6. Update the branch ref to point to the new commit
7. Pull the GitHub api until it stops returning 422's (an eventual consistency issue when GitHub is under high load)
.
About 15 total requests…
With code.storage you just post the complete diff:
```
const result = await repo.createCommitFromDiff({
});```
or better you can stream us your updated files, and we'll apply the diff for you.
```
const result = await repo
```On top of ergonomics, we have first class APIs for git notes, grep, get archive (include/exclude by blob), and other filesystem behavior that is exceeding helpful when working with LLMs.
https://code.storage/pricing
I've been look for a way to use Git for smaller, high volume document storage - think something like Google docs where every doc is a repo and every change is a commit - but also, where the vast majority of docs age out and are effectively archived and not used, but still need to be available.
This looks like it technically, I just wonder how well the pricing scales for that case of docs that might never be read again...
We have folks using us to back crms, design tools, and all kinds of "non-code" stuff.
Please reach out - would love to connect!
And agreed with other commenters about better explaining what this is - some examples and use cases side by side with the alternatives would work.
>Code Storage is designed for modern workloads: Vibe Coding platforms generating 1m+ new repos a day, AI copilots writing thousands of commits per session, teams branching and merging in real time, and apps syncing code across devices.
This is sort of a rant, skip if you must
Those 1m+ repos all have code no human has ever seen or will see. I'm afraid of being a luddite. But I can't believe we're taking vibe coding seriously, especially with these enterprise SaaS startups aimed at it. Abstractions have always come up but this is knowledge handover, this is knowledge reduction or destruction.
What happens to all of humanities greatest inventions when the current generation of developers die out? Who's going to maintain the basement? Where things haven't been abstracted? Who's learning at that level, who's keeping the knowledge alive when everyone's being told you just need to vibe instead of thinking logically?
I know why the push, people who never wanted to be developers, people who never wanted to code got into this for a paycheck or something else, they're welcoming this with both hands. I've seen people slowly lose their abilities they tried so hard to make.
I'm being fricking dramatic here all because of that blurb.