Aleph Cloud just got NVIDIA CC support and the first H200 node just landed on the network.
Confidential AI inference is the most obvious use case you can do with confidential GPU compute, but there are a lot of more subtle use cases where the verifiability enables collaboration between untrusted parties.
Anyway, this is a major milestone for the network and we'll build several products on top of it in the coming months.
Some thoughts on the current state of decentralized compute. There is a bright future ahead by focusing on the new economics of compute.
By treating compute like the commodity it has become, we can make compute markets more efficient, increase liquidity ahead of time and enable mass participation in trading the AI boom.
Your model weights are only as private as the GPU they run on.
aleph-vm 2.1.4 puts the GPU inside the boundary: confidential VMs on AMD SEV-SNP now take NVIDIA cards in CC mode, verified at boot before you unlock anything.
The first one is already live on the network: an H200.
aleph-vm 2.1.2 is out!
This release brings NVIDIA CC support to the network, improves the verifiable program attestation agent and fixes on confidential instances.
With these features, Aleph Cloud is now able to run workloads such as confidential AI inference and training.
aleph-vm 2.1 is out!
This new release extends our support for confidential computing, makes VM allocations smoother and hardens the VM volume storage layer.
Our documentation site deploys itself with a key that cannot spend a cent.
It is a CI signer with two message types, two aggregate keys, one channel. It can update the website entry. It cannot touch credits. It cannot post anything else, anywhere else.
The workflow file is public. Go and read what it is allowed to do.
"Your agent acts as you, within the permissions you set."
Those permissions bound what it does. They don't bound who can watch it do it.
An agent wired into your company's file system is a process holding live credentials to all of it. On an ordinary host, root reads that process.
Four weeks of builder posts. Everything we shipped:
→ the PR-preview workflow, trigger to cleanup
→ three commands that prove a CRN is healthy
→ the exact grant your CI signer needs
→ three storage primitives, one call each
Which one should we go deeper on?
Your CI pipeline should never hold your owner key.
Aleph's hosting action v2.1.0 hands it a narrow grant instead: two message types, two aggregate keys, one channel. Enough to ship your site. Not much else.
Key leaks? Revoke the grant, keep the wallet.
Decentralized cloud still has a human layer.
CRN operators maintain bare metal, node software, routed IPv6/TLS, runtime monitoring, and recovery.
Operators: which task is least visible to users?
Editorial illustration, not a photographed operator.
Here is the exact PR-preview lifecycle we are testing with v2.1.0 of Aleph's web3 hosting action:
PR event → deploy → preview comment → close → cleanup-only.
The `closed` trigger is explicit. We will not call cleanup successful until registry and STORE postconditions pass.
A weekend build should not lose Sunday to cloud setup.
Pick the smallest path that fits:
1. static frontend
2. long-running service
3. file/data
4. wallet-signed message
Four routes. Four verifiable outputs. Links in the replies.
Infrastructure that only exists while it's needed.
Relay Button spins up libp2p + OrbitDB relay and pinning nodes on Aleph the moment collaboration starts, then tears them down when it's over. Provisioned by need, not by guess.
Good building.
Aleph Cloud gives builders the base cloud primitives in one decentralized network: VMs, GPU instances, functions, storage, website hosting, indexing, and confidential instances.
One account, one credit balance, and the primitive your workload actually needs.
Revenue-indexed staking is different from emissions-only staking.
In an emissions model, rewards are minted on a schedule. The protocol sets the amount regardless of whether anyone is using the network.
In a revenue-indexed model, the staker share is a fraction of real usage. On Aleph, 20% of all cloud usage flows to stakers. If usage grows, the share grows with it. If usage stalls, it stalls.
And it is not passive. Stakers have a role: staking decides which nodes stay active. A node that behaves badly lowers user confidence in the whole network, so it is the stakers' duty to unstake from problematic Core Channel Nodes, or from CCNs that keep problematic Compute Resource Nodes linked.
Aleph CLI v0.14.0 is out!
* `aleph instance ssh` now supports a `-4` flag to SSH via IPv4
* `aleph account ssh-key add/list/remove` lets you manage your SSH keys
* `aleph credit summary` lets you monitor your credit usage and top ups over long periods of time.
Europe's cloud sovereignty debate should treat architecture as part of the assessment.
Moshe's thread lays out the questions we think every critical cloud assessment should ask:
Who can stop the workload?
Who can inspect it?
How can anyone verify the answers?
The EU cloud sovereignty debate is moving quickly after the Cloud and AI Development Act (CADA).
The useful question is simple: when a critical workload depends on a cloud provider, who can actually stop it, inspect it, or change the conditions under which it runs?
Want it as an agent?
An agentic model deserves an agent harness: @liberclaw_ai
Hermes-style autonomous agents on Aleph Cloud + LibertAI inference. Free tier: 2 agents, no credit card, 5 minutes to deploy. Open source.
🌐 https://t.co/GAFVi3g5gW