@albert_
Account based inUnited States
About this account
- Account based in
- United States
- Connected via
- United States App Store
Account-level information from X, not a live location or the device used for a specific post.
co-founder @ryvnai easy and secure customer cloud deployments, YC alumni, prev @palantirtech
NYC
Joined March 2021
- Tweets414
- Following349
- Followers620
- Likes993
Pinned Tweet
we've heard horror stories about self-hosted enterprise deals blowing up because the customer's devops team refused to make upgrades
they were too scared of breaking shit
don't let your $1M deal die over this and just BYOC
it is dangerous to assume you can roll back a bad release
a customer asked us for a way to blacklist releases because some database migrations leave the previous version incompatible with the new schema
if the new version fails after applying its migration in one environment, block that version from reaching the others while the team prepares a compatible fix
your deployment system should know which versions are unsafe, not just which one is newest
if you’re deploying into a customer’s cloud, updates should originate from inside their environment
something inside should call out, pull down approved changes, and execute them locally
you shouldn’t need to reach into the customer’s network every time you push a release
the customer keeps their network boundary intact, while you can continue shipping and maintaining the product
it is difficult to land an enterprise deal
only to then have your customer say they need the product running in their cloud
for completely valid security reasons, ofc
but, if you didn’t plan for that deployment model,
- every release requires coordination from both engineering teams
- every incident pulls in ... both engineering teams
- every customer environment looks different
your agents can't even help you debug without access to logs/metrics
you may have sold your product, but what you’ve committed to building and supporting is no longer saas
0 → BYOC in 1 hour
the fastest way to get sandboxes in your cloud
@archildata 🤝 @ryvnai
Read more in our launch announcement here: archil.com/post/introducing-…
Persistent Sandboxes are available today to all Archil customers in AWS regions, and can be deployed into BYOC environments (along with Archil disks) in about an hour.
even more annoying is when they do make an MCP but stick it on a higher plan tier
$10M. BYOC. F500.
you will win F500 deals faster if you just do BYOC
models progressed to a point where enterprise cyber will move too slow or block your deal if you push to use your own infra
this is the core thesis we built @ryvnai on
make it easy for everyone to do BYOC
make BYOC your advantage
you’ll unlock $100k - $1m contracts
the deal sizes are 3-10x larger because of the added security and compliance benefits
and your competitors probably can’t do it
we’ve made BYOC easy to build @ryvnai
1. your customers can self-serve setup
2. you control all updates
3. you control all configuration
4. access to logs and metrics
5. works across every cloud
6. no lock-in
Here's the exact pitch deck that helped us raise a $24M Series A in three weeks. Giving it away 6 months after announcing the round.
Earlier, I shared our pre-seed and seed decks, and 10k+ people downloaded them. This being the most recent one would be most helpful to people looking to raise an A now.
This round was led by @FirstMarkCap, with participation from @PaceCap, @upfrontvc, Darkmode, and @e2mindset, and also included strategic investments from @datadoghq and @figma ventures.
We were also backed by a bunch of stellar angels, including @gorkem, @theo, @EnoReyes, @nikitabase and @jxnlco
Download it here: ordnl.link/k5TeJF3
if your product can’t play nicely with codex or claude, you’re cut
if the mcp or cli you provide is read only, you’re also cut
your product must be entirely operable with agents
that includes onboarding
that includes integrations
that includes doing WRITES
something changed in how i buy software.
at work, i only pick services with an official MCP (posthog over plausible).
at home, same thing. i use strava because i can ask claude about my runs.
i used to care about features, now I care about interacting with my data.
no MCP means i have to use your UI.
that's a dealbreaker now.
put your entire company in 1 repo and sync out to separate repos for different use cases / sharing
one commit history for everything
agents can easily work across the entire company
bullish on this pattern
imagine this: it's 2026 and you're jumping on a zoom call to help your customer debug a self-hosted deployment
- reading logs over a screen share
- asking them to run kubectl and aws commands
- telling them what to prompt claude code
while also prompting your agent that has access to your codebase, historical incidents, architecture docs, and runbooks
sounds fucking awful compared to the way we triage and resolve incidents today in “not self-hosted deployments”
you agent should just see those logs, run those commands, and use the tools it normally uses for debugging
that's the difference between self-hosted and BYOC
that's what we're building at @ryvnai
the deployment layer that lets you ship to customer infrastructure, without humans in the loop
Albert Lam retweeted
some engineers are struggling to adapt to using agents because they are not used to being outcome oriented.
#2 macbook pro
#1 was surgical
nitter.cf/albert_/status/2089365…
12 months later with an @eightsleep and it’s easily the #3 best purchase i’ve ever made
my ac broke last night
it’s a humid 85 degrees F in the bedroom
but under the sheets, feels perfect
never let customers update your product
if they're responsible for this, they will fuck it up, and if they cause data loss, your product is blamed for not being resilient
you can control configuration even if it's hosted in their cloud
"but my customer won't let me push updates!"
then prepare all changes so it's 1-click to approve without any manual steps to mess up
that can be entirely automated and centralized so self-hosted deployments are treated like cattle, not pets
12 months later with an @eightsleep and it’s easily the #3 best purchase i’ve ever made
my ac broke last night
it’s a humid 85 degrees F in the bedroom
but under the sheets, feels perfect
data breaches involving a third party vendor
2026: 48%
2025: 30%
2024: 15%
most common access vector for breaches? exploitation of vulnerabilities (31%, 2026)
expect more enterprises to ask you to deploy in their cloud. and if you don’t want to end up in self-hosted configuration support hell, do BYOC
done right, you’ll be able to fully update, configure, and observe your deployment without any access to customer data
done wrong, you’ll losing enterprise deals or be forced to do self-hosted deployments
the last thing your fast moving team needs is friction between product improvements and your end users
you should not deploy to your customer’s cloud
unless you can maintain control over updates and configuration
self-hosted customers come with a significant support burden
@posthog famously started out with an enterprise self-hosted option, but discontinued it because their team spent an outsized amount of time on support that didn’t contribute to improving the product
the product is complex and issues could crop up in event ingestion, Redis, Kafka, Postgres, ClickHouse, or the application itself
sometimes the fix was simple (“increase disk space”) but often the issue was deeper and involved long calls with expensive engineers on both sides
but if they had the architecture in place for BYOC, and it was controllable just like a cloud region deployment, maybe history would have played out differently
posthog.com/blog/sunsetting-…
“When we launched our Kubernetes deploy, we were hoping we could get to a stage where we battle tested enough of the components. We hoped that we could automate enough to make self hosting and scaling PostHog seamless, with a minimum amount of effort.
Hosting PostHog at scale is complex. With our Kubernetes users, we've seen issues crop up in every part of the stack. In event ingestion, Kafka, ClickHouse, Postgres, Redis and within the application itself. Sometimes the fix is simple ("increase disk space"), but often the issue is something a couple of layers deep and very hard to debug, involving long calls with expensive engineers on both sides. Even something as simple as a full disk would cause their instance of PostHog to be down for hours or days.
We also learned that the tools to do that automation just don't exist. We kept finding new failure modes. When onboarding a new customer we would have to vet their engineering team for Kubernetes experience so that we'd be confident they could help us debug issues in their PostHog deploy. Folks that didn't have infra experience would often be able to get something set up, only to get stuck when something went wrong.
Despite our continued efforts to help customers and improve the experience, our small infrastructure team is spending an outsized amount of time supporting the 3.5% of users who haven't moved to PostHog Cloud or our open source Docker deployment.
By not supporting Kubernetes, we will free up a lot of time to focus on our main infrastructure priorities, which are PostHog Cloud and the open source Docker Compose deployment. Ultimately, this will lead to a better experience for the vast majority of our users.”
