Aleš

CEO / Co-founder @zeropsio - a developer-first PaaS. 15+ years of experience with development, UX and stuff. Angular enjoyer.

[Aleš @fxckdev_]

I believe coding agents do not needs sandboxes, they need proper environments, just like human developers do (https://t.co/uRKlxjkhbl).

The reason this is hard to do is that you'd need to have a cloud platform for human developers before doing this. And we happen to have one that was created with this usecase in mind long before coding agents came around (@zeropsio).

[Darren Shepherd @ibuildthecloud]

There's no sane way to run agents outside the sandbox. Read/Write/Edit calls are not integrated with the sandbox. This seems so janky. The term sandbox does not have a clear definition.

[Aleš @fxckdev_]

Definitely, marketing sites are where a lot of the focus is right now (Lovable, ChatGPT sites etc.), because that's where VCs imagine they can replace developers. But then there's everything else, things that use databases, storage, auth, search, CRUD endpoints, anything beyond a static site.

And imo in the end, unless it's just a quick marketing prototype that will be trashed later, I think it's definitely worth following good development practices anyway, even if it's a non-developer working on the thing.

[Aleš @fxckdev_]

I believe it's all about maintainability.

> Agents should handle the mechanical work of implementing, updating, and maintaining the system.

Yes, but what if something breaks and a human developer needs to look or take over - when everything is either in a black box, or the agent was let loose on a VPS, you're pretty much screwed.

I feel like the answer is a developer-first cloud platform that can handle the whole development lifecycle from local / remote development to production, and you then make the agent a power user of that.

People are reinventing the wheel. I just think about coding agents like human developers, and want to give them the same thing that would empower a human developer.

[Aleš @fxckdev_]

@FrancescoCiull4 They don't know..

[Aleš @fxckdev_]

Imagine this, but instead of a blackbox the output would be a production ready, transparent infrastructure using standard OSS for databases, queues, storage, search services, CI/CD, remote development environment where you can jump in at any point and code that sits in your GitHub repo. 🤔 👉 @zeropsio

[Rohan Varma @TheRohanVarma]

We just launched Sites into Codex!

Software creation was always about more than writing code. Sites in Codex fundamentally gives the power of end-to-end software creation to every user, no matter their technical fluency.

These Sites are fully deployed to a URL, private to workspaces, come with authentication, can have static files, and can store dynamic data in databases.

It is in preview for business and enterprise teams and will be rolling out to all workspaces over the next day. Give it a try by typing @ Sites into Codex and ask it to build anything!

This project took a massive amount of effort across hundreds of people at OpenAI - proud that we were able to get this out and excited to see what you all build with it!

[Aleš @fxckdev_]

Exactly right: "realistic development environments".

But let me take it a step further, not only they need realistic dev environments, they need environment parity between that dev environment and production environment.

That's why way to go, but you for that you have to start with cloud platform first, then add agent, not the other way around: https://t.co/uRKlxjkhbl.

Looking forward to seeing how well it works with Cursor as well. Getting there.

[Aleš @fxckdev_]

🙂.. but also the Hermes dashboard, accessible privately through the WireGuard VPN built into our CLI.. and SQLite databses backed up with Litestream, which is running as a second process (because we use system containers) @zeropsio

just a quick version (https://t.co/kLBPBbT7GC), but no worries, things are coming together.. an official Hermes recipes and much more coming soon

[Railway @Railway]

Railway's built in SSH console 🤝 Hermes Agent by @NousResearch

Video tutorial dropping soon

[Aleš @fxckdev_]

@kunalpsingh25 @aahiknsv @zeropsio > One question , What is the use case?

I'm pretty sure the use case was to build something quick and fun to get hands-on with the product of a company she just joined. Glad I could help figure this out!

[Aleš @fxckdev_]

Exactly! If you put the first two paragraphs into the chat, it would explain Zerops to you better as I, or any content on the website would, because it would be personalized to your case. 🙂

In practice Zerops could be many things to a wide range of use cases, each with need for a different explanation, each seeing benefits in different places. That's why I chose the chat as the primary CTA and targeted the rest of the page to the people where I think we'll have the highest chance to convert them.

Sorry about the bug - unhandled unpublished job posting (already filled). I plan to do a larger set of updates to the website this month, integrating https://t.co/uRKlxjkhbl more deeply, will fix it along with it.

[Aleš @fxckdev_]

@FrancescoCiull4 you start with GIFTube, you end up with YT clone

[Aleš @fxckdev_]

@noa_dfx @FrancescoCiull4 https://t.co/3RHoUTTouG

[Aleš @fxckdev_]

@FrancescoCiull4 @zeropsio @domirosari0 I have so many more analogies in my bag. Have I ever told you the one about a coctail bar?

[Aleš @fxckdev_]

Hey @domirosari0, following up personally since I'm the one responsible for the overwhelming design 🫠 there's a method to the chaos, and it's an interesting problem to solve if you happen to want to indulge more.

We're way too late to the PaaS game, 7 years building the platform (for reasons that'd make a decent Netflix comedy), so we're technically mature but only just showing up to a party where everyone already knows everyone.

The PaaS market has a pretty fixed vocabulary, eg. managed Postgres, private networking, autoscaling, preview envs, one-click deploy. Every platform ticks the same boxes. Ask anyone "do you have Postgres?" and the answer is always "yes."

But our entire reason to exist lives in the operational differences behind those same words. Our managed highly-available Postgres on a real private network isn't docker compose up on a Postgres image. SSHing into a full system container isn't SSHing into a microVM running docker. Same words, completely different thing.. and you mostly only feel it once the other version has burned you.

Which is exactly the landing-page problem. You can't sell that nuance with keywords, because the mindshare for those keywords is already owned by Railway, Vercel, Render. We'd just sound like everyone else.

Thanks to the architectural decisions and philosophy we built the platform around from the ground up, Zerops is affordable and usable for a wide range of use cases, from a $1/m Next.js static site, to infra for an agency juggling client projects, to a base layer for large distributed systems.

That's also why chat is the main CTA. To explain how the operational nuances could help you, we need to understand your use case, where you're coming from. With that, we can reframe what you'd call "overwhelming" into digestible text personalized for what you need. Recipes (one-click examples below the fold) are the second-best path a visitor could choose, you get to try the actual product without having to lift a finger (except once, after you click confirm on which tech stack you want to demonstrate).

If you don't take us up on these two "offers", the feature wall is the third, but it's for the experienced crowd, the ones that got burned by the "other version".

The whole website self-selects on purpose, as a similar philosophy is ingrained in the platform itself. We're not optimizing for deploying the first app in 30 seconds with no configs, but for day 365 of your app running. And if your needs and wants are elsewhere, it's likely you'd be happier on Railway anyway.

All that said, you're not wrong that some of it can and should be tightened, and a few sections are genuinely still unfinished, but I'm happy to say that significantly more effort over years of development was put into the platform, so an SVG not rendering properly in some edge cases definitely doesn't affect our ability to keep your apps running and your data safe.

Appreciate you actually taking the time to look. Keep that eye on us. 🫡

[Aleš @fxckdev_]

So far 4.8 seems like a HUGE downgrade from 4.7, which seemed like a big downgrade from 4.6. What's going on?

[Aleš @fxckdev_]

Yes, Incus is an integral part of making it all possible. But with the growing volume of CVEs we are taking additional steps to harden the isolation. We will run system containers inside microVMs (KVM managed by Cloud Hypervisor), providing full isolation between customers and/or projects, getting the best of both worlds.

[Aleš @fxckdev_]

The problem is that you can justify calling almost anything an agent sandbox (or hosting). I'd say there are like 8 agent-adjacent groups you need to make sense of on the market.

Imagine my frustration when I have to communicate our version of "agent sandbox/hosting" when it's a 9th segment on its own.

[Tereza Tizkova @tereza_tizkova]

since when are there so many sandbox providers??

[Aleš @fxckdev_]

@gwenshap We migrated to https://t.co/pPqI7F58dq seems to be on par with MinIO in performance.

[Aleš @fxckdev_]

@tereza_tizkova Now try explaining it with a single sentence in a space flooded with agent sandboxes and hostings :D

Here's how I used it to build a Discord-clone over the weekend https://t.co/jaFFfNZign

[Aleš @fxckdev_]

that Grok convo summarizes it well, but if I were to point couple of things out:

- the agent works against a real production infrastructure (databases, caches, searches, brokers, storages, network, balancers), not in a sandbox, whatever it produces will work on production and will be prepared for high availability and scalability
- there are natural security boundaries (while the infra of the project is 1:1 with production, it is not a production, it's just a development environment)
- it follows the same flow a human developer would (start dev server -> work on features -> verify -> deploy to stage -> verify)
- agent sits inside the project, has root ssh access to runtime containers inside the project and has their filesystem mounted, which means it can use the native Read/Write/Edit tools, as well as say start the dev server on the runtime container.. this allows it to work on multiple codebases at the same time (api, app, worker etc.)

I for example used it to lazily vibe-code a Discord clone over the weekened, see https://t.co/inlNyGdbye

[Aleš @fxckdev_]

Not in the table. We started with a real PaaS that was created from the beginning to cover the whole development lifecycle, from local/remote development to production. On the exact same infrastructure, because "but it works on my machine".

Then the idea was simple, coding agent developer has the same needs as a human developer if they are to produce anything resembling production ready code.

So we created a thin MCP layer that teaches your coding agent (that is sitting inside the project on a Linux system container with full ssh access to any other service inside the project, acting as a control plane) to be a power user of our PaaS and act within it as a senior developer with devops knowledge would.

You login with your subscription, it's very much a "bring-your-own-agent", the benefits come from the platform itself not from our own harness. Your skills, your proxies, your knowledge how to operate the agent, just our full PaaS infrastructure within which it operates.

https://t.co/kNFxi3sCmt

[Aleš @fxckdev_]

@tereza_tizkova Nope, just my own research for our docs when I needed to explain what we are doing by explaining what we are not doing, because what we are doing is conflated with all of this. 😬

[Aleš @fxckdev_]

@tereza_tizkova Agent hosting/sandboxes has such a loose definition atm, can't wait until the market has a vocabulary everyone understands.

Here's my research into like 50 agent hosting adjacent platforms and tools.
https://t.co/WMolRjP9IZ