Migrating Build21 from AWS to Ratio1

Introduction

As the Ratio1 platform approached a major on-chain release - including the pre-launch of its Proof-of-AI (PoAI) rewards and the Deeploy orchestration ecosystem - the team encouraged early adopters to migrate from big cloud providers (like AWS or Azure) to Ratio1's decentralized network. One such early adopter is Build21.io, an innovative Romanian real estate company. Build21 stands out as a pioneer by integrating blockchain technology with traditional real estate investment, using blockchain infrastructure to democratize real estate project funding and community interaction. This blockchain-driven approach made Build21 an ideal candidate to showcase how a real-world application can move off of AWS's centralized cloud onto Ratio1's decentralized cloud-edge platform.

Why Move from AWS to Ratio1?

For many startups and projects like Build21, traditional cloud platforms such as AWS offer reliability and scale, but at the cost of centralization, high expenses, and potential lock-in. Major cloud providers control roughly 80% of the cloud & AI infrastructure market, with aprox $679 billion spent on centralized cloud services in 2023. This dominance comes with drawbacks: runaway pricing, vendor lock-in, and opaque control can hinder scalability and innovation. In fact, operating on AWS often entails substantial infrastructure costs and requires specialized DevOps expertise - effectively placing much of a company's IT capabilities in the hands of the cloud provider.

Ratio1 offers an alternative path by decentralizing cloud computing. We see it described as an "AI Operating System" powered by blockchain, connecting many independent servers and devices into a distributed cloud for apps and AI workloads. Instead of handing over data and workloads to a single corporation's data center, you can keep your application and data on your own machines or trusted partners' nodes. This architecture provides intrinsic benefits aligned with current market trends: significantly lower infrastructure costs (up to 80% savings in some cases by utilizing spare capacity) and no single point of failure, while users retain ownership of their data. In short, Ratio1 aims to "provide scalable and energy-efficient infrastructure without relying on centralized cloud providers", making it attractive for organizations that value data sovereignty, censorship-resistance, and cost-effectiveness.

It's important to note that Ratio1 is not positioned as a direct competitor to big clouds like AWS, but rather as an alternative for specific needs. If a project requires running on permissioned or dedicated nodes (for compliance or trust reasons) and wants a censorship-resistant, decentralized environment, Ratio1 is designed for that scenario. The platform's philosophy - encapsulated in the "Your app, your data (or even Your AI, your Data)" mantra - reflects a paradigm shift toward user control and privacy. Build21, with its blockchain-centric model, found this especially appealing: migrating to Ratio1's network means their application infrastructure now aligns with the same decentralization ethos as their business model.

Build21's AWS Architecture and Challenges

Before migration, Build21's system was hosted on AWS as a typical multi-module, multi-tier web application. In practice, this meant several components running across multiple AWS instances:

• Two PostgreSQL databases - separate database servers holding different parts of the application data (for example, one for core transaction data and one for content or user data).

• A Content Management System (CMS) - a web-based system for managing content, likely used for Build21's website or investor portal.

• The main application (two-tier) - the front-end and back-end application logic, possibly split into a client-facing front-end and a server-side API.

Originally, these components were deployed in a relatively "bare-metal" style on AWS. In other words, instead of containerized services, the CMS and application were running directly on virtual machines (or even physical servers), each with its own environment. This kind of setup can be less portable and harder to scale. For instance, if traffic grew, the team might need to manually launch additional AWS instances or use AWS-specific services to handle scaling. There was also the overhead of managing OS-level configurations and ensuring consistency across environments. 

Key challenges with the legacy AWS setup included: maintaining multiple servers (with all the patching and updates that entails), potential under-utilization of resources (each dedicated VM might not be fully used), and being tied to AWS's pricing and ecosystem. Given Build21's rapid innovation in real estate via blockchain, they needed an infrastructure that could scale on demand, reduce costs, and provide greater control over where and how their application runs.

The Migration Process (AWS to Ratio1)

Migrating from AWS to Ratio1 required careful planning and was facilitated by one of Ratio1's partner Cloud Service Providers (CSP). This CSP acted as a specialist, guiding Build21 through the transition. The migration proceeded in a few structured steps:

1. Containerization of the Application and CMS: The first major step was converting Build21's application components from their bare-metal AWS deployment into containers. Containerization means packaging each piece of software (e.g. the CMS, the web app backend, etc.) with all its dependencies into a standardized unit (a container) that can run anywhere. This was a crucial move because Ratio1's Deeploy uses container images to distribute workloads. By containerizing the CMS and the application, the CSP ensured that these services would run identically on Ratio1's decentralized nodes as they did on AWS. 

In simple terms, a container is like a "little box" containing the app and everything it needs to run, so it behaves the same on any machine. This step eliminated the classic "it works on my server but not on yours" problem and made the deployment more cloud-native.

2. Preparing Networking (Domains and Tunnels): In a cloud environment, clients still need to reach the application via the internet. On AWS, one might use elastic IPs, load balancers, or AWS's DNS to route traffic to services. On Ratio1, the CSP used Ratio1's routing and tunnel management interface, which leverages Cloudflare Tunnel technology, to expose Build21's services. Concretely, the CSP registered Fully Qualified Domain Names (FQDNs) for the databases, CMS, and application (for example, db1.build21.ratio1.link, app.build21.ratio1.link, etc.). Each service was then configured with a Cloudflare Tunnel. Cloudflare Tunnel is a service that creates a secure, outbound connection from the host server to Cloudflare's edge network. This allows external users to reach an internal service without the server itself having a public IP or open inbound ports. In practice, a small agent (cloudflared) runs alongside the application container on the node, and it establishes an encrypted tunnel to Cloudflare. Cloudflare, in turn, handles incoming web traffic and forwards it through this tunnel to the correct service. The result is that Build21's web app and CMS became accessible at their new domains, with Cloudflare providing HTTPS, DNS, and DDoS protection automatically - all while the actual servers hosting the app remain shielded from direct public access. This setup greatly enhances security (attackers cannot directly target the origin server) and simplifies networking, since outbound connections are typically allowed by firewalls by default. The CSP configured these tunnels through Ratio1's interface, making the process straightforward.

3. "Deeploying" on the Ratio1 Network: With the application containerized and network routing in place, the CSP proceeded to deploy the containers onto the Ratio1 network using Ratio1 Deeploy. Ratio1's Deeploy is a decentralized container orchestration system - akin to a Kubernetes, but running via blockchain and a peer-to-peer node network. Using the Deeploy dashboard or API, the CSP initiated deployments for each component (databases, CMS, app) onto the network of Ratio1 edge nodes. One notable difference from a typical AWS deployment is that Ratio1 starts with horizontal scaling by default. In traditional AWS, you might launch one EC2 instance or one container task initially and then add more if needed. In Ratio1's model, the deployment can be specified to run multiple replicas across different nodes from the get-go. In fact, the platform is designed for automatic failover and distributed scaling - much like a cloud-native Kubernetes cluster that always aims for high availability. By deploying, say, 2 replicas of the Build21 web application across two independent nodes, the CSP ensured that the application would stay online even if one node went down. Deeploy's decentralized scheduling uses on-chain logic and oracle nodes (special nodes in the network) to decide where to run those containers in a trust-minimized way. There's no single "master server" deciding placements; instead, multiple orchestrator nodes reach consensus on scheduling, recorded on the blockchain. Before launching the deployment, the CSP also allocated funds (R1 tokens via USDC) for it. Ratio1 uses its utility token R1 to handle reward claiming for resource usage: running containers consumes tokens, which go to the node operators providing CPU/GPU time. The CSP acts on behalf of Build21's when funding the on-chain Ratio1 Escrow via USDC. Once CSP Escrow funded, the CSP executes the deployment - essentially submitting a "job" to Ratio1's network with the container images and desired replica count. Smart contracts verified the request (ensuring the deployer is authorized and has funds), and then the containers were launched on the selected edge nodes. In minutes, all of Build21's components were up and running on Ratio1. The Deeploy system automatically handled setting up the containers, connecting them to the previously configured Cloudflare tunnels, and even things like service discovery between the components.

4. Testing and Cutover: After deployment, Build21's team, alongside the CSP, performed validation tests. They verified that the web application was reachable at its new domain, that the CMS was functioning, and that both PostgreSQL databases were accessible to the app (likely through internal networking or secure tunnels as well). Data was migrated from AWS to the new databases as needed (this could have been done by backing up the AWS PostgreSQL and restoring it into the Ratio1-hosted PostgreSQL instances). Once everything was confirmed to be working identically to the AWS environment, Build21 could officially switch over user traffic to the Ratio1-based environment. This cutover may have been as simple as updating DNS to point to the new Cloudflare-managed domains (if the old AWS setup had its own domain names), or just announcing the new app URLs if they changed. The AWS resources were then scheduled for decommissioning, now that the entire stack was live on Ratio1.

Throughout the process, a guiding principle was to minimize downtime and complexity. By leveraging containerization and Cloudflare tunnels ahead of time, the migration avoided many risky low-level changes. Build21's team did not have to rewrite their application - they simply repacked it and redeployed it on a new kind of cloud. This demonstrates an advantage of sticking to cloud-native architecture: if your apps are containerized and have externalized configuration, you can port them between infrastructures with relatively little refactoring. The CSP noted that the end-to-end migration time can be much shorter when the source application is already following cloud-native best practices, such as using containers and CI/CD pipelines for deployment. In Build21's case, upfront effort was spent on containerizing legacy setups, but now that it's done, future updates or even cloud moves will be far easier.

Results and Benefits After Migration

With the full Build21 ecosystem deployed on Ratio1, the application is now running entirely outside of the traditional big-cloud environment. This migration yielded several notable benefits:

• Censorship Resistance and Resilience: Build21's services no longer reside on a single company's servers (like AWS). Instead, they run on a distributed mesh of Ratio1 nodes, with no central point that can be censored or shut down unilaterally. The infrastructure is inherently more robust to outages or attacks, since even if one node fails, others can continue serving the app. This aligns with Ratio1's anti-censorship and own-your-data policy - the system is designed to keep running even under adverse conditions, and no outside entity can quietly pull the plug on Build21's servers. For Build21's users and investors, this adds confidence that the platform will remain available and tamper-proof.

  
  

• Data Ownership and Privacy: By moving to Ratio1, Build21 gains greater control over its data. All application data is stored on servers (nodes) that Build21 or its chosen CSP partners operate, rather than on AWS infrastructure. This means sensitive investor or property data isn't sitting in a big tech provider's database; it's in an environment governed by Build21's own rules and the transparency of blockchain. In Ratio1, all operations (like deployments, resource usage) are logged on an immutable ledger, providing an auditable trail. The "You Own Your Data" principle of Ratio1 is now a reality for Build21 - there are no hidden data miners or unwelcome third-party access that can happen on a public cloud. This is especially valuable in finance-related industries (like real estate investment) where privacy and compliance are paramount.

  
  

• Automatic Horizontal Scaling: A subtle but important technical improvement is that Build21's application now benefits from horizontal scaling by default. On AWS, one might initially deploy a single instance of each service and then manually add more or use an auto-scaling group when traffic grows. In contrast, Ratio1's approach encourages running at least two or more replicas of each service from the start, spread across different nodes. This means Build21's app is always load-balanced across multiple servers, improving both performance and uptime. If traffic spikes, Ratio1 can deploy additional container instances (much like Kubernetes would) to handle the load, and it can scale them down when not needed. Build21 thus gains a more elastic infrastructure that can seamlessly adjust to user demand. The horizontal scaling also ties into reliability - with multiple replicas, there's redundancy. Users should experience fewer disruptions because even if one node goes offline for maintenance or due to network issues, the other replicas continue serving requests.

  
  

• Cost Efficiency and Resource Utilization: Running on Ratio1 could lower Build21's operational costs over time. The Ratio1 network utilizes many independent edge nodes, which collectively offer compute power in a marketplace-like fashion. Build21 pays only for the actual compute and storage resources they consume (via the R1 utility tokens), often at a lower rate than equivalent cloud instances. This is because Ratio1 can tap into underutilized resources globally (even idle computers) rather than relying on expensive data centers. By sharing computing resources on a global network and paying only for usage, companies can save on costs. Additionally, there are no hefty charges for data egress or premium managed services that AWS might impose. The decentralization of the infrastructure can eliminate middleman markups - node operators are directly compensated in tokens, and there's no need for large profit margins to a cloud vendor. For a company like Build21 aiming to maximize value for its investors, these savings are very attractive. Furthermore, Ratio1's incentive model (Proof-of-Availability and Proof-of-AI) ensures the network remains cost-efficient: nodes get rewards for staying online and doing real work, which encourages ample supply of computing power. In essence, Build21 now participates in a more open market for compute rather than being locked into AWS's pricing tiers.

  
  

• Strategic Alignment with Web3 Ecosystem: Build21's move to Ratio1 is not just a technical migration, but also a strategic alignment with the broader Web3 and decentralization ecosystem. Build21 is leveraging blockchain for its core business (tokenized real estate investment, NFT-based investor community, etc.), using onchain crowdfunding. By hosting their application on a blockchain-powered cloud like Ratio1, they send a strong message that their commitment to decentralization is end-to-end. This could enhance their credibility among crypto-savvy investors. It also opens the door for direct integration between Build21's application and other decentralized services. For example, because Ratio1 runs on a blockchain, Build21 could potentially use on-chain logic to trigger deployments or scale resources based on smart contracts (imagine automatically provisioning more nodes when a new property token sale is underway). While AWS has blockchain services, they are still fundamentally centralized cloud offerings. With Ratio1, Build21's tech stack is fully aligned with the decentralized ethos: from funding (blockchain-based crowdfunding) to infrastructure (decentralized cloud). This synergy could simplify compliance with emerging Web3 standards and makes the overall platform more future-proof as decentralized technology evolves.

  
  

• No Compromise on Performance: It's worth noting that the migration did not come at the cost of performance. Ratio1's architecture is built for high-performance AI and web applications. The use of Cloudflare's global edge network for ingress means users around the world access Build21's services with low latency (Cloudflare directs them to the nearest Cloudflare node, which then tunnels to the Ratio1 node). Internally, Ratio1's edge nodes can include powerful servers or even cloud VMs contributed by various operators, so Build21 could be running on hardware that is just as capable (or more so) than what they had on AWS. Additionally, Ratio1's distributed nature can allow placement of services closer to certain user clusters if needed (edge computing benefits). In short, from the end-user perspective, the application should feel as responsive as before - if not more so - and the team can scale it out easily via Deeploy if usage grows.

Conclusion

The Build21 migration showcases how a forward-thinking company can transition from a traditional cloud (AWS) to a decentralized cloud (Ratio1) to gain advantages in control, cost, and innovation. In a broader sense, this case study reflects a growing trend: organizations are exploring alternatives to the big cloud providers as they seek greater transparency and autonomy in their tech infrastructure. Decentralized cloud platforms like Ratio1 are emerging at a pivotal time - 2025 is seen as a turning point where high cloud costs, concerns over centralized control, and improved decentralized tooling are all driving interest in new models of cloud computing. For Build21, the migration was a strategic win. They were able to maintain their application functionality and user experience, while shedding the constraints of AWS. Ratio1 provided them with a trustless, blockchain-governed environment where "no central cloud, just scale" is the modus operandi (as the Ratio1 team likes to put it). It's a realm where their application nodes are permissioned and secure, but the overall network is open and resilient, striking a balance between control and decentralization. In practical terms, Build21 now enjoys an infrastructure where "Your app, your data" is the reality - the company fully owns their deployment and data, bolstered by the knowledge that the underlying network is secured by blockchain consensus and not subject to the whims of a single provider. If they ever need to expand, they can do so without negotiating new contracts or capacities with a cloud vendor; they simply use Ratio1's Deeploy to tap into more nodes, and the incentive system will attract the needed resources. Conversely, if they need to scale down, they won't be stuck paying for idle instances. Finally, it's important to emphasize that migrating to Ratio1 was not about abandoning the cloud, but about evolving with the cloud. As the Sarson Funds analysis noted, "the shift away from hyperscaler dependence is not a rejection of cloud computing, it is a necessary evolution". Ratio1 represents that evolution - a cloud that is decentralized, community-driven, and aligned with the principles of Web3. Build21's successful migration may inspire other companies to consider how they too can leverage this new breed of cloud platforms. In an era when multi-cloud and hybrid deployments are common, adding a decentralized cloud into the mix (or even replacing certain workloads entirely) can provide unique benefits. In summary, the Build21 case has proven that moving from AWS to Ratio1 is achievable and can be highly beneficial. It reduced dependencies on Big Tech infrastructure, gave Build21 fine-grained control and transparency, and did so while supporting their growth and innovation. As Ratio1 continues to mature (with features like decentralized storage - R1FS - and on-chain orchestration reaching mainnet), we can expect the migration process to become even smoother. And as more early adopters like Build21 make the leap, they are helping pave the way for a future where cloud computing is not just centralized in a few data centers, but spread across countless nodes owned by the community. This truly embodies a shift to "AI powered by you" - where anyone can own a piece of the cloud and where applications like Build21's can thrive on a platform that puts them in the driver's seat.