earayu

Two ways to use it 1. Run the agent inside the sandbox Use Treadstone when the agent itself should live in the isolated environment and keep working there over time.

2. Use the sandbox as a tool Use Treadstone when your agent runs elsewhere, but needs an isolated environment it can create, inspect, and drive on demand.

In practice, that means an agent can:

create and manage sandboxes over the CLI, REST API, or Python SDK operate what is running inside them through shell, file, browser, HTTP/WebSocket, and MCP hand the same browser session to a human when review or takeover matters

Treadstone is an agent-native sandbox platform for longer-running AI work. You can run agents inside isolated sandboxes, or treat sandboxes as tools that agents call on demand. Each sandbox is built around an all-in-one runtime: code execution, shell, file system, browser-facing surfaces, MCP, and long-running state.

Treadstone is open source, self-hostable, and built on Kubernetes.

Maintaining databases is painful, so ApeRAG uses kubeblocks for all these databases.

Yes, ApeRAG uses all these databases.

Location: China Remote: Yes

Willing to relocate: Yes

Technologies: Golang, Java, Python, Database Development, Kubernetes, Cloud, Backend, SQL, AI

Résumé/CV: https://earayu.github.io/about

Email: [email protected]

LinkedIn: https://www.linkedin.com/in/guanghui-yu-6b0784239/

I'm a database kernel engineer with business development experience, contributing to WeScale database proxy with features like read-write splitting. Previously led DDL execution engine design at Alibaba's PolarDB-X team, and actively maintain WeSQL and KubeBlocks open source communities.

KubeBlocks is an open-source database operator that enables teams to easily deploy, manage and operate any database on Kubernetes. It provides a unified approach to database management, supporting various databases like MySQL, PostgreSQL, Redis, MongoDB and more with enterprise-grade features including high availability, backup & restore, and automated day-2 operations.

How about this: https://kubeblocks.io/

A Modern MySQL proxy that supports read-write-split, read-after-write-consistency, load balancing and OnlineDDL.

https://github.com/wesql/wescale

Using it for CI/CD purposes does not violate GitHub's Terms of Service.

yeah, you are right.

> for example, don't use Actions as a content delivery network or as part of a serverless application, but a low benefit Action could be ok if it’s also low burden

Just as the wesql article states, Use Cases is Not Recommended For:

- Long-term database hosting or production workloads. - Maintaining an always-on public database endpoint. - Circumventing GitHub Actions usage policies.

I was thinking about EC2's default instance storage - it's ephemeral and gets wiped when you restart or stop the instance. Without paying for EBS volumes, EC2's storage is non-persistent by design.

just use it for CI/CD

GitHub Actions is completely free, and you can always use free S3-compatible storage like Cloudflare R2, making the entire setup cost nothing.

VPS has two main drawbacks:

Many don't guarantee persistent disk storage It's not ideal for CI/CD scenarios where you need ephemeral databases for testing But you're right - if you need a simple, always-on database, a $5 VPS might be a good choice.

Yep, GitHub Actions isn't meant for production deployment - it's a CI/CD service with a 6-hour limit per run.

But that's the cool thing about WeSQL - you can run it anywhere! Just fire it up like any other container. For production, throw it on ECS/EKS and you're good to go.

Sure. That's the fascinating aspect of WeSQL database - its compute-storage separation allows you to run the database anywhere while data persists in S3.

You can shut down the compute service and restart it anywhere else - the data will simply restore from S3.