If you’re anything like me, chances are your home lab is also built on a budget. Maybe you’re using some leftover hardware, or maybe you’ve found a ridiculously affordable VPC provider (I highly recommend checking out Webtropia for low-cost options). Either way, you probably don’t have access to dedicated load balancers or advanced networking devices.

After countless hours of tweaking and scouring the internet for a comprehensive guide to setting up MetalLB with basic hardware, I hit a wall. So, I got creative. In this blog, I’ll share how I managed to set up a Kubernetes cluster using k3s, kube-vip, and MetalLB — all on budget-friendly resources. Let’s dive in!

Tools You’ll Need

To replicate this setup, here’s what you’ll need:

• k3s: A lightweight Kubernetes distribution.

• k9s: A terminal-based tool for monitoring and administering your cluster.

• kube-vip: For handling VIPs (Virtual IPs).

• MetalLB: To act as a load balancer for your Kubernetes cluster.

Optional but handy tools:

• A GUI-based tool like ArgoCD for managing workloads after installation.

Step-by-Step Guide to Setting Up Your Cluster

1. Provision Your VPCs

For this guide, I used three VPCs as the control plane for my Kubernetes cluster. You can extend this setup to add worker nodes as needed. If you don’t have physical hardware, consider using affordable VPC providers like Webtropia. The key is to have at least three nodes to achieve high availability.

2. Install k3s

On each of your nodes, install k3s:

curl -sfL https://get.k3s.io | sh -

For the master node, initialize the cluster and note down the token:

k3s server --cluster-init

For the additional nodes, join them to the cluster using the token:

k3s agent --server https://<master-node-ip>:6443 --token <your-token>

3. Configure MetalLB

MetalLB is a load balancer implementation for bare-metal Kubernetes clusters. Here’s how to set it up:

1. Install MetalLB:

    kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/main/manifests/metallb.yaml
   

2. Create a ConfigMap: Configure an IP address pool that MetalLB can use:

    apiVersion: v1
    kind: ConfigMap
    metadata:
      namespace: metallb-system
      name: config
    data:
      config: |
        address-pools:
        - name: default
          protocol: layer2
          addresses:
          - 192.168.1.240-192.168.1.250
   

   Replace the addresses range with a range suitable for your network.

4. Set Up kube-vip

kube-vip simplifies high availability for your Kubernetes control plane. Install kube-vip as a DaemonSet:

kubectl apply -f https://kube-vip.io/manifests/kube-vip-ds.yaml

Then, configure kube-vip to manage the virtual IP for your control plane. For example:

kube-vip install \
  --vip 192.168.1.100 \
  --interface eth0 \
  --controlplane \
  --arp

5. Test Your Setup

Once everything is up and running, test your cluster by deploying a sample application:

kubectl create deployment nginx --image=nginx
kubectl expose deployment nginx --port=80 --type=LoadBalancer

Access the application through the load balancer’s IP address.

For detailed instructions, refer to the Kubernetes Documentation.

When Do You Actually Need Kubernetes?

Let’s be honest: Kubernetes isn’t for everyone. If you’re building a simple application or a prototype, Kubernetes is overkill. A few Docker containers or a lightweight VM setup might be all you need.

Kubernetes becomes valuable when scaling is a challenge. If your application has unpredictable spikes in usage or requires automatic scaling, Kubernetes’ orchestration capabilities are unmatched. But for predictable workloads, Docker Compose or Portainer might be a better choice.

Conclusion

Setting up Kubernetes on a budget is entirely possible, even without cloud infrastructure or expensive hardware. With tools like k3s, MetalLB, and kube-vip, you can create a fully functional cluster on old hardware or low-cost VPCs. While it might take some effort, the experience is incredibly rewarding and a great way to level up your skills.

Have you found better solutions or hit roadblocks in your own Kubernetes setup journey? Share them in the comments below — I’d love to hear your stories!

Resources That Helped Me (and Where I Got Stuck)

• MetalLB Documentation

• k3s Documentation

• Some Helpful YouTube Videos:

  • https://www.youtube.com/watch?v=CbkEWcUZ7zM&t

  • https://www.youtube.com/watch?v=Yt_PWpn-97g

  • https://www.youtube.com/watch?v=6k8BABDXeZI

  • https://www.youtube.com/watch?v=UoOcLXfa8EU&t

Afrobeats is more than a genre; it’s a cultural movement, pulsating with rhythm, energy, and stories that resonate globally. Yet, despite its stark rise, there hasn’t been a platform dedicated to objectively rating and promoting Afrobeats music while connecting its creators to DJs and audiences worldwide. This realization led us—a group of DJs and artists—to build Play Afro.

The idea behind Play Afro was born from necessity. As DJs and artists ourselves, we saw a gap in how Afrobeats music is promoted and consumed. Platforms often rely on subjective opinions or algorithms disconnected from the actual performance of songs. This doesn’t do justice to the artists or their craft.

We envisioned a high-quality platform where artists can showcase their work to new audiences. DJs serve as gatekeepers, rating and ranking songs based on how they perform at real-world events like clubs, weddings, and festivals. Audiences can discover top-rated Afrobeats tracks, curated by professionals. The core value of the platform lies in fact-based ratings provided by DJs. These ratings are not just opinions but reflections of how songs resonate with diverse crowds. Each week, we publish charts of top-performing songs, creating a credible benchmark for excellence in the Afrobeats space.

Bringing this vision to life was no small feat. As the Technical Lead, my role was to lead the design and development of a robust platform that meets the needs of artists, DJs, and audiences. Here’s a closer look at how we built Play Afro.

Building a platform as dynamic as Play Afro required careful consideration of tools and technologies. Our stack reflects the need for scalability, performance, and seamless user experiences. The frontend is built with Next.js, leveraging its server-side rendering (SSR) for fast page loads and search engine optimization (SEO). The backend is powered by Node.js with a RESTful API design to ensure scalability and maintainability. For the database, we use a combination of PostgreSQL for structured data and Redis for caching and real-time interactions. Authentication is integrated with Auth0 for secure and seamless user authentication. Given the global popularity of Afrobeats music, our audience spans continents—from Asia and South America to Europe and Africa. It was essential to prioritize a geo-redundant deployment from the start, ensuring minimal latency for users worldwide. A cloud platform was the ideal choice, and we selected AWS as it met our geo-redundancy requirements while reducing technical debt and accelerating deployment. This approach allowed us to quickly launch and begin gathering user feedback.

Given the global and mobile-first nature of our target audience, we opted to start with a Progressive Web App (PWA). PWAs offer a native-like experience while being accessible across devices and platforms without the need for app downloads and installation. This approach allowed us to validate our concept quickly, reach a broader audience with minimal friction, and lay a foundation for future native mobile apps once demand grows. While the desktop version is already fully featured, we’re committed to expanding into native mobile apps to cater to an ever-growing user base.

Building Play Afro came with its fair share of challenges. Ensuring the ratings provided by DJs are credible and representative of real-world performance was a top priority. We developed mechanisms to prevent duplicate ratings and verify DJ participation. With the potential for high traffic during chart releases and voting periods, our backend had to handle sudden spikes without compromising performance. DJs and artists needed real-time feedback on song performance. Implementing WebSockets for live updates was critical but technically complex. Coordinating a remote development team across different time zones added another layer of complexity. Clear communication, structured sprints, and robust tools like Jira and Slack were essential for ensuring smooth collaboration. Launching a platform with such ambitious goals required balancing speed with quality. It was a constant push to meet deadlines while maintaining the integrity of the product.

While I drive the technical aspects of Play Afro, this platform represents a collaborative vision. My co-founders, DJ Bizi Brown and Prince Amaho, are not only established figures in the music world but also embody entrepreneurial and product management expertise. DJ Bizi Brown, an international DJ with a strong background in product management, and Prince Amaho, a seasoned entrepreneur and music manager, applied their strategic insights to shape the platform. Their roles extended far beyond artistry; they actively contributed to conceptualization, rigorous testing, and effective promotion, ensuring Play Afro serves its community with both innovation and authenticity.

Play Afro is just the beginning. As we move forward, we’ll continue to refine the platform, build native mobile apps, and explore new features to amplify the reach of Afrobeats music. Our mission remains steadfast: to create a credible, vibrant space where artists, DJs, and audiences connect and thrive. Building this platform wasn’t easy. But with a shared vision and relentless determination, we’ve laid the groundwork for something truly transformative. I look forward to what’s next and invite you to join us on this journey.

• Try out Play Afro and discover the rhythm of Afrobeats like never before at playafro.com

• Check out African DJ charts at African DJ Charts

In an era dominated by always-online software and endless subscription models, it’s time to pause and reflect: Is this really the best way forward? While subscription models make powerful software more accessible—allowing users to pay only for what they need instead of bearing the upfront cost of full ownership—they also enable businesses to leverage cloud platforms to reduce infrastructure overhead and accelerate development, fostering innovation.

However, as users, developers, and business owners, we’ve grown accustomed to apps that demand constant internet access, collect vast amounts of data, and lock us into recurring fees. This raises an important question: Is this model sustainable for everyone? What if there’s a healthier, more balanced alternative? Enter local-first and offline-first design principles.

The Problem: The Hidden Costs of Always-Online Software

Always-online software has become the default. From note-taking apps to project management tools, most require a persistent internet connection. While this model offers convenience, it comes with significant downsides:

1. Connectivity Dependence: Without a stable internet connection, these tools become useless. Think about the frustration of losing access to critical files during a flight or a rural retreat.

2. Privacy Concerns: Centralized systems store sensitive user data on remote servers, increasing the risk of breaches and misuse.

3. Subscription Fatigue: Users face an ever-growing list of monthly payments. For developers, this model prioritizes retention over genuine user satisfaction.

4. Environmental Impact: Constantly syncing data to the cloud consumes energy, contributing to a growing carbon footprint [1].

For businesses, cloud-based applications necessitate subscription models to finance running costs before turning a profit. Startups often operate at a loss for extended periods, covering costs upfront or entirely. This frequently results in sacrificing user data to sustain operations.

In the end, the user bears the ultimate price—either by contributing to cloud costs through subscription fees or by involuntarily offering their data.

As someone who frequently travels for work, I’ve experienced firsthand how unstable internet connections can make it nearly impossible to get work done on the go. These challenges led me to critically rethink how software is built. Does an app really need to be online to function? Would an offline-first approach be better?

It’s clear this always-online approach isn’t as user-friendly or sustainable as we’ve been led to believe.

The Solution: Local-First and Offline-First Design Principles

Local-first and offline-first design offer a radical rethinking of software. Instead of treating the internet as a constant requirement, these principles prioritize autonomy, resilience, and privacy:

1. Local-First Software: Data is stored and processed on the user’s device by default. The cloud, when used, acts as a backup or synchronization tool—not the primary storage.

2. Offline-First Design: Apps are designed to function seamlessly without an internet connection. Users can access and edit their data offline, with changes syncing when connectivity is restored [2].

This approach isn’t just theoretical; it’s already being implemented in popular apps like WhatsApp and Spotify as well as in tools I’ve developed, such as Readme TTS, which lets users listen to articles offline, and NutriScan, which categorizes receipts without needing an internet connection.

The Benefits: Why This Matters

1. Empowering Users

With local-first software, users regain control over their data. Files and records stay on their devices unless explicitly shared, reducing dependence on third-party servers.

2. Resilience in Any Situation

Offline-first apps work anywhere, whether you’re traveling, experiencing network outages, or working in low-bandwidth areas. They’re designed to be reliable, no matter the circumstances.

3. Cost-Effectiveness

For both users and developers, the local-first approach eliminates the need for expensive server infrastructure and recurring cloud storage fees [3].

4. Better Privacy and Security

Storing data locally means fewer opportunities for breaches and less invasive data collection by corporations. This aligns with growing user demand for ethical, privacy-focused software [4].

5. Environmental Sustainability

By reducing reliance on constant cloud synchronization, local-first apps lower their energy consumption and carbon footprint [5].

The Vision: A Sustainable Software Ecosystem

Adopting local-first and offline-first principles isn’t just a technical decision—it’s a philosophical one. It’s about rejecting the status quo of “always online” in favor of creating tools that respect users’ autonomy, privacy, and time.

For solo developers and small teams, this model is especially empowering. By focusing on local-first solutions, they can build robust, user-friendly software without needing to maintain costly cloud infrastructure or compete in the cutthroat subscription economy. As someone building software, I’ve found that local-first design lets me prioritize quality over scalability.

Imagine a world where software works for users, not the other way around. Where apps are resilient, private, and genuinely helpful—even offline. That’s the promise of this movement.

The Case for the Cloud

Does this mean the cloud is the wrong place for building and deploying applications? Absolutely not. The cloud has undeniable benefits, particularly for businesses managing complex, scalable applications. It provides flexibility, accessibility, and the ability to quickly deploy solutions without upfront infrastructure costs. For many organizations, especially startups, cloud platforms enable rapid experimentation and scaling, making it easier to focus on delivering value without worrying about maintaining hardware.

The key is intentionality. Not every app needs to rely entirely on the cloud. Providers should critically evaluate which features truly benefit from cloud-based functionality and which could operate more effectively offline or locally. By thoughtfully balancing these approaches, we can create a more sustainable and user-friendly ecosystem—one that leverages the best of both worlds.

My Final Thoughts

It’s time to rethink how we build and use software. As developers, we have the tools and knowledge to create healthier alternatives. As users, we have the power to demand better.

Let’s embrace local-first and offline-first principles, not just as a design choice but as a commitment to a better future—for ourselves, our users, and even those indirectly impacted by our products.

References

[1] Environmental Impact

• The Environmental Costs of Data Storage

• Energy Consumption Optimization in Cloud Data Centers

• From the Clouds Descends a Greener Future

[2] Examples of Offline-First Apps and Architectures

• Building Offline-First Apps Using MVVM

• Offline and Thriving: Building Resilient Applications

• Offline-First Applications: Ensuring Seamless UX

• Offline-First Approach with Reactive JavaScript Databases

[3] Cost Comparison Studies

• Cloud vs. Local Storage: Which is Cheaper?

• Cloud vs On-Premise Cost Comparison Guide

• Cloud versus On-Premise Computing

[4] Trends in Privacy-Focused App Development

• The Rise of Privacy-Focused Apps

• Offline-First Design Is the Future of Mobile Apps

• 10 Mobile App Development Trends

[5] Carbon Footprint of Always-Online Systems

• The Carbon Footprint of Our Digital Lifestyles

• A Guide to Your Digital Carbon Footprint

• What Is a Digital Carbon Footprint?

Image Credits

Photo by Anna Shvets