All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Looking for a little help with infrastructure for Rhelma
Hey guys,
I'm currently working on a project called Rhelma:
GitHub:
https://github.com/rhelma
It's an open-core AI-native workspace platform that I'm building from the ground up.
The basic idea is to create a workspace where people, AI agents and different services can work together, rather than having AI as just another chatbot.
I'm trying to build the platform so AI agents can actually work with the workspace, understand its context, interact with services, automate things and eventually become a real part of the user's working environment.
It's still in active development, so there is a lot left to do, but quite a bit of the infrastructure is already in place.
The stack is mainly Rust + SvelteKit, with PostgreSQL, Redis, Qdrant, Meilisearch, realtime services, AI orchestration, Docker/Kubernetes, etc.
At the moment I'm looking for a decent server to use for development, testing and getting the whole thing running together.
Something around:
3+ cores
4GB+ RAM
NVMe
Linux
would already be very useful. I'm flexible on the exact specs/location.
If anyone here is running a hosting company and has an unused server, discounted box, developer deal, or would simply like to support the project with some infrastructure, I'd definitely be interested.
It doesn't necessarily have to be free either. A good LET deal would work too.
In return, I'm happy to mention the provider on the Rhelma site/project as an infrastructure supporter, and if things work out, I'd be happy to keep using the provider as the project grows.
I'm mainly looking for something I can use for the next stage of development rather than a production cluster at this point.
If anyone has something suitable, feel free to reply here or PM me.
Thanks guys 
Comments
So the AI build tool calls by itself? So you basically build everything from the ground up by prompting artificial neural network
Btw, thanks. I can access and use every feature through the API without needing to be logged in. Thanks.
@thenet First, understand and improve the security. At least fix the website logo. And honestly, even the themes suck.
Not exactly. I think you're looking at Rhelma more like an AI coding/build tool, but that's not really what I'm building.
The bigger idea behind Rhelma is a decentralized community/network of nodes, where each node can support multiple workstations.
Each workstation has its own context and memory, and can have its own role or domain — for example, it could be a general-purpose workstation or specialize in development, research, finance, media, etc.
These workstations aren't isolated. They can interact with other workstations and nodes, request capabilities or services from each other, and exchange value through the network.
I'm also working on a value/transaction layer for this, so the network can have its own mechanism for requests, contributions and exchanges between participants.
Local LLMs are an important part of the idea. A node can run its own local model, allowing each workstation to work with its own context and memory without having to send everything to a centralized AI provider.
So the long-term idea is closer to:
Nodes → Workstations → Local AI + Memory + Context → Specialized capabilities → Communication & Value Exchange
rather than:
Prompt → LLM → Generate an application
And just to clarify, Rhelma is still under active development and design. There hasn't been an official public release yet. What you're seeing right now is a development version, not the finished product.
So yes, there are going to be bugs, rough UI elements, incomplete security hardening, and other issues at this stage 😄. That's exactly what I'm working through before the official release.
Regarding your API finding though, I'll definitely investigate it. If there's an endpoint that is exposing functionality that should require authentication, that's useful feedback at this stage.
And yeah... I'll put the logo and themes on the list too 😄
@thenet So honestly, what ur describing is exciting but it's also kind of a security nightmare in a specific way, because ur stacking three things that are each already hard on their own
peer to peer networks, autonomous AI agents, and actual money/value moving around.
Yeah, that's exactly what makes it interesting — and difficult. 😄
I've been working on Rhelma for about 8 months now, with around 28 Rust services and a lot of code behind it. The interesting part is that AI is also used in the development process itself to build, review and improve the system.
I agree that P2P + autonomous AI + value exchange creates serious security challenges. That's something I'm actively working on before release.
Rhelma is still in development and design, and there hasn't been an official release yet. So there are definitely things to improve along the way. 😄
FTFY
The first big issue is identity. Nodes and workstations need real, verifiable identities. Otherwise anyone can spin up fake nodes, run a Sybil attack, fake identities, burn reputations, and start over. A node running multiple workstations is another risk. If the node gets compromised, everything on it is exposed unless the workstations are properly isolated with containers or VMs.
The biggest concern for me is the local LLM + workstation communication. If workstation A sends something to workstation B and B's LLM treats it as trusted context, you've got distributed prompt injection. A malicious message could make the AI leak memory or take actions the user never approved.
These are the right attack surfaces to consider. RHELMA does not treat a node/workstation as trusted just because it is registered. The trust model is based on cryptographic identity, attestation, capability admission, and policy enforcement. A node identity is bound to a key pair, and participation requires verification rather than self-asserted metadata, which prevents trivial Sybil identities from immediately gaining network privileges.
For multi-workstation nodes, the isolation boundary is the execution sandbox, not the physical node. Workloads are separated through container/VM isolation, resource limits, and least-privilege policies, so compromising one workspace should not expose the entire node state.
The LLM communication issue is also handled by treating inter-workstation messages as untrusted data. A message flow is not directly injected into the model context; it must pass identity verification, authorization checks, policy filtering, and prompt-injection detection before becoming actionable context. In other words, the system separates data transport, context admission, and agent authority instead of assuming that internal communication is safe
"Verification rather than self asserted metadata" sounds good, but verified by who? What's backing it? Bootstrap authority, staking, web of trust, hardware attestation? Otherwise a well funded attacker can pass the same check multiple times.
Yes. The architecture includes layered trust verification (identity, attestation, admission control, and authorization). The specific trust anchor (hardware attestation, staking, allowlist, etc.) is deployment-dependent
where did you get the idea from? gpt?
Be careful with prompt injection detection. It's still an unsolved problem. No classifier catches every prompt injection. Use it as one layer, but don't make it the thing deciding if a message is safe. The real backstop is capability control. If a malicious prompt gets through, the agent should still only have access to tightly scoped actions.
And Once a message passes all the gates and becomes trusted context, what stops the agent from authorizing a transfer it shouldnt?
But "deployment-dependent" can turn into "undefined" pretty fast. A fixed interface, regardless of the anchor, should answer things like can it be revoked, can it be cloned, what's the forge cost, and how fast does revocation propagate?
Otherwise, weak anchors end up showing "verified: true" the same as strong ones.