DEV Community: Niklas

Harnessing the power of GitOps with Rig

Niklas — Mon, 19 Feb 2024 14:25:47 +0000

GitOps has among the cloud-native community become a standard or a given for how you should manage what is installed in your Kubernetes clusters. At Rig.dev, we even use GitOps for managing our own Kubernetes clusters.

What GitOps is and all the advantages it brings is out of scope of this article. If you want to know more about it, you can read this excellent one-pager: https://www.gitops.tech/.

In the process of designing our product we have been talking to 100s of engineering leaders from companies of various sizes, and GitOps has been a recurring topic in our chats. This raises the question: How does the Rig.dev platform integrate with the GitOps pattern? In this article, we will delve deeper into this topic.

Seamless co-existence to experience the full value of GitOps

We aim for Rig to seamlessly integrate into any Kubernetes setup, providing a natural fit. This principle guides our platform design in several ways:

We avoid imposing specific components or methodologies on our users.
Rig is designed not to dominate the Kubernetes cluster; it should coexist peacefully with workloads managed outside the Rig platform.
Whenever feasible, we strive to integrate Rig into the broader cloud-native ecosystem.

When opting for GitOps, one of the significant advantages is the comprehensive audit log it provides for any changes made to the Kubernetes cluster. Allowing a platform to make changes to the cluster without passing through the GitOps toolchain would undermine the integrity of this audit log.

Therefore, to develop a platform that seamlessly aligns with clusters using GitOps for change management, we must be capable of integrating with the GitOps workflow.

How we at Rig.dev integrate with GitOps

As a first step towards integration with GitOps, we have implemented a feature where Rig can write changes to files in a Git repository instead of directly modifying a Kubernetes cluster.

We do not enforce a specific choice between Flux or Argo CD. Instead, we simply commit YAML manifests, leaving it to you to select a GitOps tool responsible for applying these changes to the underlying cluster.

This GitOps integration allows you to maintain all Kubernetes cluster modifications within your GitOps workflow. For detailed instructions on setting this up in your Rig.dev environment, please refer to the GitOps section in the documentation: https://docs.rig.dev/operator-manual/gitops

Upcoming Rig-features related to GitOps

Currently, we support creating resources from the Rig platform, which are then synced to Git. We do not currently support creating resources in Git that are then adopted by the Rig platform. If you would like to see this feature implemented, please voice your opinion on the GitHub issue:
https://github.com/rigdev/rig/issues/607.

In some setups, changes to the Kubernetes cluster need to be approved through a
pull request workflow. We do not currently support this feature, but we will be implementing it soon. The pull request feature is being tracked in this GitHub issue: https://github.com/rigdev/rig/issues/608.

Due to the asynchronous nature of a GitOps workflow, we aim to provide further support for this in our dashboard. For example, it should be easy to see whether changes you made have actually been applied to your cluster, as well as any potential problems in the GitOps pipeline. We are tracking this feature here: https://github.com/rigdev/rig/issues/609.

Introducing Rig.dev

At Rig.dev, we offer an application platform for Kubernetes. We empower developers with our developer-friendly deployment engine that simplifies the process of rolling out, managing, troubleshooting, and scaling applications on Kubernetes. The platform provides elevated Kubernetes-abstractions, cloud-native integrations, and powerful tooling that unlocks true developer experience and -productivity while enabling DevOps/Platform Team to manage risk at scale.

We would love to have a chat and give your a live demo, so please schedule a call with us through this link. If you want to take it for a spin yourself to experience the platform then sign up here

Why we made our Startup Open-Source

Niklas — Wed, 20 Sep 2023 11:52:59 +0000

We built Rig.dev as an open-source platform from day one, and there's a good reason behind that. If you've ever worked with Kubernetes, Docker, or Git, you know the value of open-source isn't just in the code—it's in the community and transparency that comes with it. In this post we’ll share some of our key reflections, when we chose to build Rig.dev open-source.

A humble favor 🤗:

We are on a mission to reach 1k stars on Github. Would you consider supporting by giving us a star on Github? It encourages me and the rest of the team to produce more, high-quality content weekly.

Our Github: https://github.com/rigdev/rig

A Global Audience From Day One

Going open-source isn't just a philosophical choice; it's a strategic one. By making Rig.dev open-source, we instantly tap into a global network of developers and DevOps teams. This isn't just about broadening our user base—it's about enriching our platform with diverse inputs and expertise.

Traditional commercial models often take time to scale globally, but with open-source, global reach is organically built into the model itself. Having previously worked with various commercial models, we see open-source not just as a community-building tool, but as a key component of our go-to-market (GTM) strategy.

The Power of Community Feedback

A strong community isn't just a vanity metric to show on your website—it's about active collaboration and swift feedback. With Rig.dev, we've experienced firsthand the power of community-driven insights. This isn't just about validation; it's about rapid iteration.

The immediate feedback we receive allows us to refine and enhance our platform at a pace that traditional models can't match. For us, that has been extremely valuable and we feel both grateful and privileged to have such a strong community behind us already.

Building Trust Through Transparency

By having our codebase openly accessible, we're taking a big step towards building trust and transparency with our users and the community. Users and potential customers can review the code independently, which on our end fosters accountability and transparency.

This commitment to openness and scrutiny will hopefully help us build a strong foundation of trust with our community. This is also closely connected to us being able to lower the barrier of adoption and reducing the classical problem of vendor lock-in as much as possible.

Lowering the Barrier to Adoption

One of the biggest challenges for new technology is getting people to try it out. By open-sourcing our platform, we're addressing this head-on. Free access, coupled with comprehensive guides and documentation, allows companies and individual users to test our platform without any upfront costs.

Additionally, users aren't locked into a proprietary solution, ensuring flexibility and encouraging broader adoption within the Kubernetes ecosystem.

Reducing Vendor Lock-in

We're committed to reducing vendor lock-in concerns by only introducing thoughtful and flexible abstraction layers that don’t force unnecessary lock-in on the user. While no solution can eliminate dependency risks completely, this flexibility ensures that users are not tied to us as a vendor.

This approach empowers companies to maintain control over their tech-stack, making our solution a low-risk option within the Kubernetes ecosystem while still providing immense value.

From Small Teams to Enterprise

In the future, we plan to adopt an open-core model, where the foundational core of our product remains open-source and freely accessible. As organizations scale to an enterprise level or obtain specific requirements, they will have the option to access premium features and enhanced capabilities through a paid version. This approach allows us to provide cost-effective solutions for individual users or smaller companies as well as comprehensive support for enterprises seeking advanced functionality.

Wrapping up

Thank you for taking the time to learn about our decision to build Rig.dev open-source. We're excited about the possibilities of the decision, or our own early community, and the broader Kubernetes-community.

We look forward to working with you and hearing your feedback as we continue to evolve and improve Rig.dev.

We'd love your support

We are not done building yet, and we would love your support on Github.

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

What do you think about our approach?

5 Open-Source Projects We’re Using to Build Rig.dev

Niklas — Tue, 19 Sep 2023 10:17:08 +0000

Outlines

Introduction

Steganography

Project Setup

Core Concepts

Mapping Techniques

Bit Manipulation for Hiding Images

Bit Manipulation for Revealing Images

Bit Manipulation for Reconstructing Images

Implementation Details

Results and Visualization

Limitations and Future Work

Conclusion

Summing Up the Journey

Technical Achievements

Key Takeaways

One of the key elements that make our platform, Rig.dev what it is today, is our love for the Open-Source community.

Why? We believe in transparency, community, and the kind of innovation that only comes from a diverse, collaborative effort.

In this article, we will give you a detailed look into the Open-Source projects that powers Rig.dev. From our CLI to our frontend, each tool has been carefully selected to align with our mission and offer the best possible experience for both developers and DevOps teams. Enjoy!

About Rig.dev

Rig.dev offers an Open-Source application platform for Kubernetes. We empower developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability.

Our developer-friendly deployment engine simplifies the process of rolling out, managing, debugging and scaling applications. On top, our platform includes a Dashboard, CLI, and CI/CD pipelines that seamlessly integrate with GitHub Actions.

We need your help

We are not done building yet, but we would love your support on Github along the way. It motivates us to keep making Rig.dev better 🙏
Our Github Project: https://github.com/rigdev/rig

1. Cobra: The Backbone of Our CLI

Cobra is a go-to library for building CLIs in Go (pun intended). What makes it a standout choice is its ease of use right from the get-go (yup, again). You can create a functional CLI with just a few lines of Go code and as your project scales, Cobra scales with you, offering both complexity and extensibility.

Why We Chose Cobra for Our CLI

Rich Functionality Out-of-the-Box
Cobra comes packed with a ton of built-in features that make CLI development a breeze:

Subcommands: Easily create nested commands, making your CLI more organized and intuitive.
Global, Local and Persistent Flags: Define flags that work across all commands, are specific to single commands or are inherited by subcommands.

Positional Arguments: Handle positional arguments effortlessly with validation functions and guards, making your CLI more flexible while retaining control.

Automatic Help Command: Cobra auto-generates help commands saving you the hassle of manual documentation - With the option of customizing the commands of course.

Extensibility: Play Well with Others

One of the key strengths of Cobra is also its extensibility. While Cobra takes care of the CLI's structure and the command-line parsing, you're free to integrate it with other tools to get the job done however you like:

Interactive CLI with PromptKit: We use PromptKit to add interactivity and style to our CLI. This makes the user experience more engaging.

Dependency Injection with UberFX: We leverage UberFX to inject dependencies directly into our commands, making the code cleaner and more maintainable.

Example: Creating and deploying a redis capsule

Create a build with a redis image.
Instances in the capsule listen on port 6379 and the same port is exposed using a load balancer.
We specify that when the container starts, it runs the command "redis-server /usr/local/etc/redis/redis.conf" which is how you start the redis server with a specific configuration file.
We then mount that config file into /usr/local/etc/redis/redis.conf from the local redis.conf file.
Finally, we deploy 3 instances

2. UberFX: Streamlining Dependency Injection in Go

UberFX is a robust dependency injection framework crafted by Uber for Go. In the absence of dependency injection, developers often find themselves manually constructing a myriad of objects or, worse, depending on unstable global state.

Why we use UberFX

We chose UberFX because we've seen it scale effectively, from small applications to massive codebases. Some of our team members have firsthand experience with its successful implementation at Uber, so we're confident in its ability to scale with Rig.dev as we grow.

Real-World Example: How We Use UberFX in Rig.dev

Structuring Components
In Rig.dev, all our components follow a similar initialization pattern. We specify the dependencies of each component in its constructor, and UberFX takes care of constructing everything in the right order. Here's a simplified example:

type service struct {
    logger         *zap.Logger
    userRepo       repository.User
    secretRepo     repository.Secret
    projectService project_service.Service
}

type newParams struct {
    fx.In
    Logger         *zap.Logger
    UserRepo       repository.User
    SecretRepo     repository.Secret
    ProjectService project_service.Service
}

func NewService(p newParams) Service {
    return &service{
        logger:         p.Logger,
        userRepo:       p.UserRepo,
        secretRepo:     p.SecretRepo,
        projectService: p.ProjectService,
    }
}

We then group the constructors of related components into Fx Modules:

var Module = fx.Module(
    "service",
    fx.Provide(
        capsule.NewService,
        user.NewService,
        auth.NewService,
        project.NewService,
        group.NewService,
    ),
)

and from there it's a simple matter to construct the entire Rig server. We also use FX to execute non-constructor functions needed to setup the server:

// Slightly simplified Rig Server construction 
rigServer := fx.New(
    service.Module,
    repository.Module,
    gateway.Module,
    telemetry.Module,
    fx.Supply(config),
    // Non-constructor function needed to setup the server 
    fx.Invoke(
        func(cfg config.Config, s *pkg_service.Server) {
            s.EmbeddedFileServer()
            s.Init()
        },
    ),
)

Fx also handles the various lifecycles of executing the Rig server, e.g.

// Simplified execution of Fx's lifecycles which power the Rig server
func run(ctx context.Context, rigServer *fx.App) error {
    if err := rigServer.Start(ctx); err != nil {
        return err
    }

    sig := <-rigServer.Wait()
    var err error
    if sig.ExitCode != 0 {
        err = fmt.Errorf("aborted: signal %v", sig.Signal.String())
    }

    if err := rigServer.Stop(ctx); err != nil {
        return err
    }

    return nil
}

UberFX has significantly simplified the way we build and run Rig.dev. It allows us to construct our application out of reusable components, streamlining the development process and ensuring that we can scale efficiently as our codebase grows.

3. Kubebuilder

Kubebuilder has established itself as the go-to tool when it comes to creating API extensions for Kubernetes. Sure, one can craft controllers using a raw Kubernetes API client, and technically, you could do this in any programming language.

But here's the catch: Kubernetes is written in Go, and so is a significant chunk of its ecosystem. To ensure seamless integration and reduce potential issues with tooling, it's makes perfect sense to stick with the most widely adopted tool in the ecosystem.

Insights into Our Upcoming Integration with Kubebuilder

As Rig.dev evolves, we're constantly looking for ways to enhance our platform's capabilities. One of the significant shifts we're planning is transitioning some of our APIs from being solely within Rig.dev to being more deeply integrated with Kubernetes. Our vision? To introduce a Custom Resource Definition (CRD) that will encapsulate our "capsule" concept (pun very much intended).

The Potential Benefits This Integration Will Bring to Our Users

By making this move, we're essentially making Rig.dev more compatible with the broader Kubernetes ecosystem. This has a couple of key advantages:

Ecosystem Compatibility: As we integrate our APIs more deeply into Kubernetes, Rig.dev becomes more compatible with the broader Kubernetes ecosystem. This means better interoperability with other tools and platforms that Kubernetes professionals use daily.

Familiarity: Developers who are already well-versed with Kubernetes APIs will find our APIs more intuitive and familiar. This reduces the learning curve and allows them to be productive right off the bat.

Flexibility: With our APIs being more Kubernetes-native, developers gain more flexibility in how they deploy, manage, and scale their applications on Rig.dev.

Our upcoming integration with Kubebuilder is all about reducing friction and making life easier for devs and DevOps teams that are already knee-deep in Kubernetes. We're excited about the added compatibility and the doors it will open for more integrated and streamlined operations.

4. Go-ContainerRegistry: Simplifying Remote Registry Operations

Go-ContainerRegistry is a Go library that provides a straightforward way to interact with container image registries. If you've ever needed to explore remote registries, pull images, or manipulate image metadata, this is the tool you'd likely reach for.

Why Do We Use Go-ContainerRegistry?

The primary reason we use Go-ContainerRegistry in Rig.dev is for its unified approach to working with container images. Whether you're dealing with various remote registries, a local daemon, or even local image files, Go-ContainerRegistry provides a consistent interface for all these operations. Here's why that's crucial for us:

Unified Interface: No need to juggle different tools or libraries when working with images. Go-ContainerRegistry offers a single, unified API for all your needs.

Cross-Registry Support: Whether you're pulling from Docker Hub, Google Container Registry, or any other registry, you can do it all through the same API calls.

Local and Remote: The library isn't just for remote operations; you can also use it to interact with your local Docker daemon or manipulate local image files.

5. Vue + Nuxt: Powering Our Frontend Development

Why We Chose Vue & Nuxt

When it comes to frontend development, time-to-market is often a critical factor. Vue, known for its simplicity, coupled with Nuxt, allowed us to roll out an MVP in record time. But don't let the simplicity fool you; Vue and Nuxt are among the most powerful frameworks you can use for frontend development.

Benefits of Using Vue & Nuxt

Simplicity & Quick Onboarding: If you're comfortable with HTML, CSS, and JavaScript, you'll find Vue to be incredibly approachable. The learning curve is less steep compared to other popular frameworks like React and Angular, making it easier to onboard new developers.

Performance & Lightweight Footprint: Vue is lightweight, which translates to better performance. When pitted against other popular frameworks like React and Angular, Vue consistently outperforms them (Benchmarks: https://krausest.github.io/js-framework-benchmark/current.html), especially in terms of initial load times and runtime efficiency.

Development Productivity: Nuxt takes Vue's simplicity and supercharges it, making it even easier to build complex applications. It handles a lot of the boilerplate and configuration for you, allowing devs to focus more on application logic and less on the underlying infrastructure.

Stellar Documentation: Both Vue and Nuxt come with comprehensive documentation, making it easier for new or existing developers to get up to speed. This is a significant advantage when it comes to scaling the team or introducing new features.

Why Do We Use Vue & Nuxt in Rig.dev?

The unified approach that Vue and Nuxt offer aligns well with our philosophy at Rig.dev. Just like we aim for a unified way of working with images across registries, daemons, and local files in the backend, Vue and Nuxt provide a cohesive and efficient way to build and manage our frontend.

Wrapping Up

Our journey with these open-source projects is not just about leveraging their capabilities; it's about being part of a larger community. A community that thrives on collaboration, innovation, and the shared goal of making technology more accessible and efficient.

As we continue to grow and refine Rig.dev, we remain grateful to the developers and communities behind these projects. Their dedication and expertise will have an instrumental role in our future growth. We're excited about the what's coming, and we're committed to giving back to the open-source world, contributing to its growth, and ensuring that Rig.dev remains at the forefront of Kubernetes application platforms.

Join our community

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

Thanks from Team Rig.dev 🙏

The 5 Biggest Risks and Rewards of Adopting Kubernetes

Niklas — Mon, 18 Sep 2023 13:42:41 +0000

If you've been anywhere near the cloud computing space in recent times, you've likely come across the name Kubernetes. But what is Kubernetes exactly?

Simply put, Kubernetes is an open-source container orchestration platform. Containers allow developers to wrap up an application in a consistent environment, regardless of where it's run. Think of them as lightweight, standalone executable software packages that come with everything the software needs to run: code, runtime, system tools, libraries, and settings. Great in concept, but as you scale, managing these containers manually or through scripts can become a tough task. Enter Kubernetes.

Kubernetes steps in to automate the deployment, scaling, and operations of these application containers across clusters of hosts. Initially developed by Google, it was handed over to the Cloud Native Computing Foundation (CNCF) and has since witnessed an almost meteoric rise in popularity.

And its growing footprint is not just hype. The surge in Kubernetes adoption is a testament to the tangible benefits it brings to the table. Yet, like any technology, it comes with its own set of challenges. This post is all about exploring those, alongside the undeniable perks.

As we navigate this landscape, I'll also introduce you to Rig.dev, our open-source application platform crafted specifically for Kubernetes, designed to make your workflow in Kubernetes smoother and more efficient.

Rewards of Adopting Kubernetes

Scalability

One of the major advantages that often gets highlighted when talking about Kubernetes is its ability to scale. But why is scalability so central to Kubernetes, and how exactly does it pull it off?

Horizontal Pod Autoscaling: With Kubernetes, scaling isn’t just about adding more resources to a single component (vertical scaling). Instead, Kubernetes scales horizontally. What this means is that it can automatically increase or decrease the number of pod replicas based on the CPU usage or other select metrics. This ensures that resources are used optimally and costs are managed efficiently.

Cluster Autoscaler: This is another gem in the Kubernetes arsenal. If a pod can’t be scheduled because resources are tight, the cluster autoscaler kicks in, adjusting the size of the cluster, ensuring that there are enough nodes for all the pods to run smoothly.

Manual Scale: Sometimes, you still might want to be at the helm. Kubernetes doesn’t take away this control. You can manually scale the number of replicas as you see fit, depending on anticipated loads.

Flexibility and Portability

Transitioning to the cloud has revolutionized how we develop and deploy, but that shift has also brought its own set of challenges. One of the most pressing issues? Ensuring flexibility and portability across diverse environments. Kubernetes, yet again, steps up to solve this.

Multi-cloud Environment Support:

In the rapidly evolving world of cloud services, many organizations have found value in not tying themselves down to a single cloud provider. There are various reasons for this approach, ranging from cost efficiency, redundancy, or leveraging specific features from multiple providers.

Here’s where Kubernetes shines. It’s inherently designed to work seamlessly across multiple cloud platforms. Whether you’re using AWS, Google Cloud, Azure, or a combination thereof, Kubernetes ensures consistent deployment and operations across these environments.

Freedom of Workload Movement:

Being tied down is never ideal. With Kubernetes, you’re not only deploying consistently across diverse environments but also moving your workloads freely.

Let’s break this down a bit:

Containerization: At the heart of this flexibility is containerization. As mentioned earlier, Containers package up the application and all its dependencies. This means, essentially, what runs on your local dev machine will run anywhere Kubernetes does, be it cloud or on-premises.

API-driven Architecture: Kubernetes’ API-driven approach means that its operations and behaviors are consistent across all environments. This uniformity ensures that no matter where you're deploying, your workloads function the same way.

Storage Orchestration: Kubernetes offers a uniform API for provisioning storage across various cloud providers.

No Lock-ins: Kubernetes offers a level of portability across cloud providers, making transitions, for instance from AWS to Azure, relatively painless. However, it's essential to note that this portability primarily applies if you're not deeply integrated with specific services unique to a cloud provider, such as AWS's S3. While Kubernetes provides flexibility, it's crucial to be cautious about the additional services and tools from cloud providers that might lead to vendor lock-in.

While Kubernetes aims to provide a "Write Once, Run Anywhere" experience, the reality is often more complex. If your application relies on APIs or services specific to a particular cloud vendor, then the promise of seamless portability becomes more challenging to realize. Kubernetes does alleviate many environment-specific concerns, but it's not a silver bullet for complete cloud-agnostic operations.

Resilience and High Availability

When running applications at scale, downtime is a nightmare scenario. One of the primary reasons Kubernetes is turning heads in the DevOps community is its strong focus on resilience and high availability. Let’s drill down into how Kubernetes keeps your applications robust and operational.

Self-Healing Mechanics:

Kubernetes doesn't just launch containers; it nurses them. If a container fails, Kubernetes automatically replaces it. If a node dies, the platform moves the orphaned containers to healthy nodes. The system even kills containers that aren't responsive to health checks. All this happens automatically, without manual intervention. Here's a quick breakdown of self-healing features:

Pod Lifecycle: Kubernetes constantly checks the status of pods. If a pod fails a health check, Kubernetes can restart it or even reschedule it to another node.

Node Health: If a node fails, Kubernetes redistributes the load by moving the containers to healthy nodes.

Ensuring High Availability

Downtime doesn’t just hurt technically; it's a business nightmare. Kubernetes has several built-in features tailored to squash downtime:

Replication: By running multiple instances of your application (known as replicas), Kubernetes ensures that if one instance goes down, the others are there to pick up the slack. Additionally, with the use of anti-affinity rules, Kubernetes can distribute these replicas across different nodes. This ensures that in the event of a node failure, not all replicas are affected.

Load Balancing: Kubernetes evenly distributes traffic to your application instances, thereby preventing any single point of failure.

Multitenancy

In large-scale ecosystems, especially within large organizations, ensuring resource and application isolation is paramount. Kubernetes has firmly positioned itself as a frontrunner in the realm of multitenancy, addressing the intrinsic needs of diverse user bases while maintaining stringent security norms. Here's how it achieves this:

Role-Based Access Control (RBAC) for Fine-grained Permissions:
In a multitenant environment, the principle of least privilege is crucial. RBAC in Kubernetes enables administrators to specify who can do what and where. Whether it’s accessing a pod, reading a config map, or deploying a new service, RBAC ensures that users and services only get access to what they need, nothing more.

Namespaces for Resource Segregation:
Kubernetes uses namespaces as a primary tool for implementing multitenancy. It allows you to segment cluster resources, creating isolated environments for different teams or projects. Think of it as creating virtually separated rooms in a large house where each team can operate without intruding on another's space.

Network Policies for Traffic Control:
While namespaces delineate cluster resources, network policies dictate the communication rules between pods. By defining explicit ingress and egress rules, you can ensure that only authorized entities communicate, making cross-namespace or unwanted accesses a non-issue.

Encryption and Security Protocols:
Beyond traffic control, Kubernetes emphasizes end-to-end encryption, ensuring that data, whether at rest or in transit, is shielded from prying eyes. This is not just about data integrity; it’s about fostering a secure environment that stands robust against potential breaches.

In essence, multitenancy in Kubernetes isn't just about cohabiting multiple applications. It's about ensuring that these applications can coexist seamlessly, without stepping on each other’s toes, and without compromising on security. With features tailored for isolation and the principle of least privilege, Kubernetes demonstrates its commitment to serving large organizations with varied and complex requirements.

Risks of Adopting Kubernetes

The Complexity of Kubernetes

I think it’s clear by now that Kubernetes brings a lot of value to the Dev and DevOps table. But It's also important to be transparent about its complexities.

The Steep Learning Curve:

Jumping into Kubernetes isn't like diving into a new programming language or tool. It's more like learning a new ecosystem:

Concept Overload: Pods, services, ingress, nodes, replicas, volumes... the list goes on. Kubernetes introduces a multitude of new concepts and terminologies, which can be overwhelming for newcomers.

Declarative vs. Imperative: While Kubernetes’ declarative nature (defining the desired state) can be a blessing, it's a paradigm shift for those accustomed to imperative methodologies. Wrapping one’s head around this can take time.

YAML, YAML, and More YAML: Configuration in Kubernetes is predominantly done through YAML files. These can become cumbersome and error-prone, especially when managing large clusters.

The Web of Microservices:

Inter-Service Communication: As applications are decomposed into smaller services, managing how these services talk to each can become a challenge. Tools like service meshes (e.g., Istio) can help, but adds another layer of complexity.

Data Management: While breaking apps into microservices, data consistency becomes a challenge. Distributed databases and transaction management require careful planning and execution.

Configuration Sprawl: With numerous services come numerous configurations. Ensuring consistency and managing these configurations can be a daunting task.

While Kubernetes aims to simplify orchestration, it’s essential to understand that this simplification often translates to the abstraction of complexity. Beneath the surface, there's a lot going on, and diving deep without adequate preparation can lead to pitfalls.

Resource Consumption

Kubernetes is often praised for its operational efficiency. But it’s crucial to dig deeper into what operational efficiency might mean in terms of resource consumption. The harsh reality is that Kubernetes can be a resource-hungry beast, both in terms of compute and human capital.

Compute Resources

Control Plane Overheads: Running the Kubernetes control plane itself incurs resource overhead. We’re talking about etcd, API servers, and various controller components here. Each has its own CPU and memory requirements.

Pod Resource Limits: While pods can be lightweight, they can quickly become resource hogs if not configured with resource limits. Without proper settings, you could be looking at CPU and memory spikes that affect cluster stability.

Network Load: As you scale, so does the need for network resources. Service meshes, ingress controllers, and load balancers all add layers that consume network bandwidth.

Human Resources

Expertise: Understanding Kubernetes’ nuances requires skilled personnel, and skilled Kubernetes engineers don’t come cheap.

Maintenance: From ensuring high availability to rolling out updates, maintaining a Kubernetes cluster is a full-time job that requires dedicated staff.

Resource consumption is often the elephant in the room when it comes to Kubernetes adoption. It’s essential to have a solid understanding of what your actual needs are versus what Kubernetes demands, especially if you’re operating in a resource-sensitive environment.

Rig.dev's Contribution to Simplify Kubernetes:

Rig.dev offers an open-source application platform for Kubernetes. We empower developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability.

Our developer-friendly deployment engine simplifies the process of rolling out, managing, debugging and scaling applications. On top our platform includes a Dashboard, CLI, and CI/CD pipelines that seamlessly integrate with GitHub Actions.

Kubernetes is undeniably a powerhouse, and combined with Rig.dev, we believe it can be a game-changer. The combined synergy ensures that as a developer, you spend less time wrestling with deployment issues and more time doing what you love: writing and iterating on code.

Even though we're still in the building phase, we would love it, if you'd consider giving us a star on GitHub 🌟: https://github.com/rigdev/rig

Conclusion

Whether you're a developer knee-deep in application deployment or a DevOps professional striving for operational excellence, Kubernetes is both a promise of scale and a challenge of complexities

Rewards: Kubernetes offers unprecedented scalability, allowing systems to grow as the demands intensify. It also provides flexibility and portability, ensuring that applications aren't confined to a specific cloud provider or local environment. Then there's the allure of resilience and high availability, making sure that applications stay robust against failures.

Risks: But then, there's the other side of the coin. The complexity of Kubernetes is undeniable, and the learning curve can be steep. The security concerns add another layer of diligence, with the ecosystem requiring constant vigilance against potential threats. And then, we have the often-ignored, but crucial resource consumption aspect – Kubernetes, with all its prowess, can be resource-intensive.

Use your judgment

Adopting Kubernetes (or any technology, for that matter) shouldn't be a decision based on hype or peer pressure. It should be a calculated move, a result of understanding the benefits and potential pitfalls, and then aligning them with organizational and project-specific needs.

Support our own Open-Source application platform for Kubernetes on Github

I hope this article gave you a better understanding of Kubernetes and while we're still in the building phase, we would love it, if you'd consider giving us a star on GitHub 🌟: https://github.com/rigdev/rig

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

Why we launched earlier than what felt comfortable

Niklas — Wed, 13 Sep 2023 14:00:35 +0000

It’s been 10 days since we launched Rig.dev - our open-source application platform for Kubernetes, and in all honesty, we had our worries about making our repository public for everyone. Suddenly it was about to get very real.

Why the worry? We still had a lot of features and developer workflows we wanted to improve but had limited knowledge on what to prioritize and what to push back.

The benefits of launching early and building in public, therefore quickly became very clear to us; show the world what we are building and get ongoing feedback from the community on if we actually address one of their problems, and if our solution is the right one.

In this post, we have gathered some reflections and our initial learnings from launching early and building in public.

Required reflection

First thing’s first. We had to be no less than excellent at explaining our solution. What was our vision? What key problems were we trying to solve for our users?

By taking a step back and diving into these questions as a team we got a great boost in alignment on what path to take so we could build a platform that truly solved the needs of our users.

Shortened feedback-cycle

One of the most important factors in our early launch was the community. Getting early (and sometimes ruthless) feedback on everything from our problem statement and wording on our website to features and documentation were absolutely essential for us in terms of refining our solution.

And oh boy did we get feedback! Thanks to our community we now have a lot of insights into how our platform and solution is perceived, helping us improve communication over the next couple of weeks.

Internal motivation

After releasing, it suddenly was clear to us that there in fact was a high level of interest in what we were working on, and that motivated us to keep pushing forward to deliver the best possible solution for our users and ourselves.

So even though building in public can be frightening - and sometimes even demotivating due to the overwhelming amount of honest feedback - we stayed relentlessly motivated.

Public Accountability

We also discovered, that the public accountability that comes along with building in public can be a strong force. We now have a community of developers waiting for new updates and releases, as well as companies waiting for us to come back with an updated version based on their feedback.

This motivates us to continuously improve our platform and keep moving, while constantly driving ourselves to be agile in our development process.

Wrap up

Overall, we hope that this has given insight into our reasoning for launching early and building in public. Until now it has been a powerful approach for us, and we're excited to see where it takes us next as we continue to grow.

Building in public requires a well-balanced mix of engaging with the community as well as making sure we stay on course. But as our community continues to grow, we will always prioritize engaging and making sure community members feel part of the development.

We are excited and grateful by the support we have received so far. While we're still in the building phase, we would love it, if you'd consider starring us on GitHub 🌟: https://github.com/rigdev/rig

Also, we're actively seeking feedback, bug reports, and feature requests in our Rig.dev Slack Community – so please join us here!

10 Open Source Alternatives To Proprietary Software

Niklas — Wed, 13 Sep 2023 07:58:40 +0000

We're Rig.dev, a new kid on the open-source block. We know how frustrating it can be to feel locked into pricey proprietary software, so we've put together a list of "10 Open Source Alternatives" that can give those big-name tools a run for their money. No jargon, no sales pitch – just some cool free tools we think you'll love.

A humble favor 🤗:

We are on a mission to reach 1k stars for our own Open-Source project on Github. Would you consider supporting by giving us a star on Github? It encourages me and the rest of the team to produce more, high-quality content weekly.

Our Github: https://github.com/rigdev/rig

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

Table of contents: Medusa vs. Shopify; Postman vs. Hopscotch; Slack vs. Rocket Chat; Google Chrome vs. Brave; n8n vs. Zapier; Webflow/Framer vs. Webiny; Bit.ly vs. Dub.co; Calendly vs. Cal.com; Airtable vs. NocoDB

Medusa: The Shopify Alternative

You've probably heard of Shopify, the big player in the game. But there's a new contender on the block: Medusa. Let's break down the good, the bad, and the nitty-gritty of these two.

Pros of Medusa compared to Shopify:

Do It Your Way: Medusa is open-source, which means you can tweak it however you like. Want a neon pink checkout button? Go for it!

Keep Your Cash: Unlike Shopify, which nabs a bit of your sales unless you use their payment system, Medusa doesn't dip into your pockets.

Pick Your Home: With Medusa, you decide where to host your store. It's like choosing between renting an apartment or building your own house.

Power to the People: Medusa gets love from its community. That means regular updates, cool new features, and a bunch of folks ready to help out.

No Secrets: Open-source means you can see everything that's going on behind the scenes.

Cons of Medusa compared to Shopify:

Ready Out of the Box: Shopify's got a ton of built-in goodies and a massive app store. Medusa is still catching up in this department.

Less DIY: With Shopify, a lot of the tech stuff is handled for you. Medusa? You're in the driver's seat, but that means you've got to handle the bumps in the road too.

Name-Dropping: Everyone knows Shopify. Medusa is still the new kid in school.

Conclusion:

Choosing between Medusa and Shopify boils down to your specific needs and technical expertise. If you value flexibility, customisation, and control over costs, Medusa is the compelling choice. However, if you're looking for a platform with a proven track record, extensive built-in features, and robust support, Shopify remains a strong contender.

Hopscotch: The Postman Alternative

You've likely heard of Postman, the big shot in the API testing world. But there's an open-source challenger stepping into the ring: Hopscotch.

Pros of Hopscotch compared to Postman:

Free as a Bird: Being open-source, Hopscotch won't cost you a dime. This can be a big win for small teams or individual developers watching their budget.

Community Vibes: Open-source tools like Hopscotch thrive on community input. That means you've got a bunch of passionate folks constantly improving it and adding cool new features.

Transparency: With Hopscotch, there's no behind-the-scenes mystery. You can see every line of code, ensuring you know exactly what's going on.

Lightweight: Hopscotch tends to be more lightweight than Postman, which can be an advantage if you're looking for something less resource-intensive.

Customisation Galore: Being open-source, if there's a feature you need that's missing, you can add it yourself or rally the community to help out.

Cons of Hopscotch compared to Postman:

Feature-Packed: Postman has been around the block and has a ton of built-in features. It's like the Swiss Army knife of API testing.

Slick User Interface: Postman's UI is polished and intuitive, making it easy for newcomers to get started.

Collaboration Features: With its team collaboration tools, Postman makes it a breeze for teams to work together, share collections, and keep everything in sync.

Extensive Documentation: Postman's been in the game for a while, so they've built up a vast library of tutorials, guides, and community posts to help you out.

Integration Ecosystem: Postman offers integrations with a wide range of other tools, making it easier to fit into existing workflows.

If you're all about open-source, love to tinker, and are looking for a lightweight tool, Hopscotch might be your new best friend. But if you're after a feature-rich environment with a proven track record and don't mind shelling out some cash for premium features, Postman's still a solid bet. As always, it's about finding the right tool for your needs.

Rocket Chat: The Slack Alternative

When it comes to team communication tools, Slack has been the go-to for many. But hold on, there's an open-source challenger in the ring: Rocket.Chat. Let's break down how these two stack up with a straightforward look at three pros and cons of Rocket.Chat compared to Slack.

Why Rocket.Chat Might Just Rock Your World:

Tweak and Tune: Rocket.Chat is open-source, which means if there's something you don't like or something you think could be better, you (or your tech team) can jump in and customize it. Your Rocket.Chat can be as unique as your team's favorite inside jokes.

Wallet-Friendly: With Rocket.Chat, you can avoid some of those pesky costs that come with premium versions of proprietary software like Slack. Plus, being self-hosted, you have more control over potential future price hikes.

Your Data, Your Rules: Hosting Rocket.Chat on your own servers means you have full control over your data. No need to worry about third-party access or where your data is stored.

Where Slack Might Still Have the Upper Hand:

Plug and Play: Slack is known for its user-friendly interface and ease of setup. For those who aren't tech-savvy, Slack's straightforward approach can be a blessing.

Integrations: Slack's been around the block and has a massive library of app integrations. Whether it's Trello, Google Drive, or that niche tool your team can't live without, Slack probably has an integration for it.

The Cool Kid's Club: Slack's popularity means that many people are already familiar with it. Onboarding new team members or collaborating with partners might be smoother if they've already used Slack before.

Conclusion:

Rocket.Chat offers a world of customisation, cost savings, and data control that's hard to beat. But if you're looking for a hassle-free setup, a vast array of integrations, and widespread familiarity, Slack's still got game. As always, the best choice depends on what your team values most!

Brave: The Google Chrome Alternative

When it comes to web browsers, Google Chrome has been the reigning champ for quite some time. But there's a new contender that's been making waves: Brave. Built on the same Chromium engine as Chrome, Brave promises a different kind of browsing experience.

Pros of Brave compared to Google Chrome:

Privacy First: Brave takes privacy seriously. It blocks third-party ads and trackers right out of the box, meaning you don't have to fiddle with settings or add extensions to stop companies from following you around the web.

Speed Demon: Thanks to its ad-blocking capabilities, Brave often loads pages faster than Chrome. Fewer ads and trackers mean less data to download, making your browsing experience snappier.

Get Paid to Surf: Brave has a unique feature called Brave Rewards. By opting into privacy-respecting ads, you can earn BAT (Basic Attention Tokens) that you can keep or give to your favorite websites as a tip. Chrome doesn't offer anything like this.

Cons of Brave compared to Google Chrome:

Extensions Galore: Chrome's Web Store is a treasure trove of extensions and apps. While Brave is built on the Chromium engine and therefore is able to install all Chrome extensions, there might occur compatibility issues with some due to their heavy focus on privacy and ad-blocking.

Google Ecosystem: If you're already invested in the Google universe—think Google Drive, Google Photos, Google Meet—Chrome offers seamless integration with these services. Brave can access them, but it's not quite as smooth.

Stable and Reliable: Chrome has been around for years and has a proven track record of stability and performance. Brave is newer and, while robust, hasn't had as much time to iron out all the kinks.

Conclusion:

If you're big on privacy and like the idea of a faster, rewarding browsing experience, Brave could be a game-changer for you. But if you're a heavy user of Chrome extensions or deep into the Google ecosystem, Chrome might still be your best bet.

n8n vs. Zapier: The Automation Arena

In the world of workflow automation, Zapier has long been a household name, helping businesses and individuals connect their favorite apps and automate tasks. Enter n8n, an open-source alternative that's been turning heads with its unique approach. Let's dive into how n8n measures up against Zapier.

Pros of n8n compared to Zapier:

Customisation King: Being open-source, n8n offers unparalleled customisation. If there's a specific feature or integration you need, you can build it yourself or tap into the community to help. This level of flexibility is something proprietary platforms like Zapier can't match.

Cost-Effective: n8n can be self-hosted, which means you can potentially save a lot, especially if you're running a large number of workflows. With Zapier, as your needs grow, so does the subscription cost.

Data Privacy: With n8n's self-hosting option, you have complete control over your data. It stays on your servers, ensuring you know exactly where it is and who has access. This contrasts with cloud-based solutions like Zapier, where data is processed on external servers.

Cons of n8n compared to Zapier:

User-Friendly: Zapier is known for its intuitive interface, making it easy for even non-techies to set up and manage workflows. n8n, with its more developer-oriented approach, might have a steeper learning curve for some.

Massive Integration Library: Zapier boasts over 3,000 app integrations. While n8n is rapidly growing its list, it hasn't reached the same extensive number of out-of-the-box integrations as Zapier.

Reliability & Support: With its established presence, Zapier offers robust reliability and a dedicated support team. While n8n has a passionate community, it might not provide the same level of immediate, professional support that a mature platform like Zapier does.

Conclusion:

n8n offers a world of customisation, cost savings, and data control that's hard to beat for those comfortable with a more hands-on approach. However, if you're looking for a platform with a vast array of ready-to-use integrations, a user-friendly interface, and dedicated support, Zapier remains a formidable choice. Your ideal pick will depend on your specific needs and technical comfort level.

Webiny: The Webflow & Framer Alternative

In the realm of web design and development, tools like Webflow and Framer have made a name for themselves, offering intuitive interfaces and powerful design capabilities. But there's a new open-source player in town: Webiny.

Pros of Webiny compared to Webflow & Framer:

Open-Source Flexibility: Webiny's open-source nature means you can customize it to your heart's content. If there's a feature or integration you need, you're not limited by proprietary constraints. This level of adaptability is something platforms like Webflow and Framer, being proprietary, can't fully match.

Cost Considerations: Webiny can be more cost-effective in the long run, especially for larger projects or businesses. While Webflow and Framer come with subscription costs, Webiny's open-source model can lead to significant savings, especially when considering self-hosting.

Full Control Over Data: With Webiny, you have the option to self-host, giving you complete control over your data and its security. This contrasts with cloud-based solutions like Webflow and Framer, where your data resides on external servers.

Cons of Webiny compared to Webflow & Framer:

Intuitive Design Interfaces: Both Webflow and Framer are renowned for their user-friendly design interfaces. They offer drag-and-drop functionality and visual design tools that make it easy for designers to bring their visions to life, even without deep coding knowledge. Webiny, while powerful, might have a steeper learning curve for pure designers.

Rich Template & Component Libraries: Webflow and Framer come with extensive libraries of templates, components, and animations. This can significantly speed up the design process. Webiny, being newer, might not offer the same breadth of ready-to-use design elements.

Community & Support: Webflow and Framer have large, established communities and dedicated support teams. This means a wealth of tutorials, forums, and resources are available. Webiny, being newer to the scene, is still growing its community and support infrastructure.

Conclusion

Webiny offers a compelling open-source alternative with customization capabilities, potential cost savings, and data control. However, for those who prioritize intuitive design interfaces, a vast array of design elements, and established community support, the combined strengths of Webflow and Framer remain hard to beat.

Penpot: The Figma Alternative

In the design world, Figma has emerged as a favorite, known for its collaborative features and sleek interface. But there's an open-source contender stepping into the spotlight: Penpot.

Pros of Penpot compared to Figma:

Open-Source Advantage: Penpot's open-source nature means it's continuously evolving with contributions from the community. This allows for a level of adaptability and customization that proprietary platforms like Figma might not offer.

No Cost Barriers: Penpot, being open-source, is free to use. While Figma offers a free tier, advanced features and larger team collaborations require a paid subscription. With Penpot, you can access all features without worrying about subscription costs.

Self-Hosting for Data Control: Penpot gives you the option to host on your own servers. This means you have complete control over your data, its security, and where it's stored, a feature not available with Figma's cloud-only model.

Cons of Penpot compared to Figma:

Matured Ecosystem: Figma has been around longer and has a more matured ecosystem. This includes a vast library of plugins, integrations, and community-contributed resources that can enhance the design process.

Real-time Collaboration: One of Figma's standout features is its seamless real-time collaboration. Multiple designers can work on a single project simultaneously with live updates. While Penpot offers collaboration features, it might not be as refined as Figma's.

Performance & Reliability: Figma's performance, especially with complex designs and prototypes, is robust and reliable. Being a newer tool, Penpot is still in the process of refining its performance and ironing out any kinks.

Conclusion

Penpot offers a fresh, open-source perspective to the design tool landscape, with cost benefits and data control that many will find appealing. However, for those who value a vast ecosystem, real-time collaboration, and proven performance, Figma remains a formidable choice.

Dub.co: The Bit.ly Alternative

Bit.ly has been a staple for many users. However, the open-source community has presented an alternative: Dub.co.

Pros of Dub.co compared to Bit.ly:

Open-Source Flexibility: Dub.co's open-source nature means it's continuously evolving with contributions from the community. This allows for a level of adaptability and customisation that proprietary platforms like Bit.ly might not offer.

Cost Considerations: Dub.co, being open-source, is free to use. While Bit.ly offers a free tier, its advanced features and analytics come with a premium price tag. With Dub.co, you can access all features without worrying about subscription costs.

Data Privacy & Self-Hosting: Dub.co gives you the option to host on your own servers. This means you have complete control over your data, its security, and where it's stored, a feature not available with Bit.ly's cloud-only model.

Cons of Dub.co compared to Bit.ly:

Established Reputation: Bit.ly has been around for a long time and has built a reputation for reliability and performance. This longstanding presence means many users trust and are familiar with its services.

Extensive Integration Options: Bit.ly offers a wide range of integrations with other platforms and marketing tools, making it easier for businesses to incorporate link management into their existing workflows.

User-Friendly Interface: Bit.ly is known for its intuitive interface, making it easy for users to create, manage, and analyze their shortened links. While Dub.co offers a robust platform, newcomers might find Bit.ly's interface more straightforward.

Conclusion:

Dub.co presents a fresh, open-source perspective to link management, offering customisation, cost benefits, and enhanced data control. However, for those who value a tried-and-true platform with a vast array of integrations and an easy-to-use interface, Bit.ly remains a strong choice. Your ideal tool will depend on your specific needs and how you prioritise features.

Cal.com: The Calendly Alternative

When it comes to scheduling meetings and appointments, Calendly has been the go-to platform for many. But there's a new open-source alternative that's catching attention: Cal.com.

Pros of Cal.com compared to Calendly:

Open-Source Flexibility: Cal.com is open-source, which means you can customise it to fit your specific needs. Whether it's adding a unique feature or integrating it with other tools, you have the freedom to make it your own. This is something Calendly, being a proprietary platform, can't offer.

Cost-Effective: Cal.com is free for individuals, and being open-source, you can self-host it to avoid subscription fees. Calendly, on the other hand, has a free tier but limits you to one event type and lacks some advanced features unless you upgrade to a paid plan.

Data Privacy: With the option to self-host, Cal.com gives you complete control over your data. You know exactly where it's stored and who has access to it, which is not the case with Calendly's cloud-based model.

Cons of Cal.com compared to Calendly:

User Experience: Calendly has been around for a while and has a polished, user-friendly interface. It's easy to set up and manage appointments, even for those who aren't tech-savvy. Cal.com, being newer, might have a steeper learning curve.

Integration Options: Calendly offers a wide range of integrations with popular platforms like Google Calendar, Office 365, and Zoom. While Cal.com is working on expanding its integration options, it hasn't yet reached the same level as Calendly.

Community and Support: Calendly has a large user base and offers robust customer support, including a wealth of tutorials and resources. Cal.com, being a newer and open-source platform, relies more on community support, which might not be as immediate or extensive.

Conclusion:

If you're into trying new things, love a good freebie, and value keeping your data close, give Cal.com a whirl. But if you want a tried-and-true tool that's easy to use and has solid support, Calendly's still a solid bet.

NocoDB: The Airtable Alternative

You've probably seen Airtable around, with its colorful grids and easy drag-and-drop vibe. But there's a newcomer that's making some noise: NocoDB. Let's break down how these two stack up.

Pros of NocoDB compared to Airtable:

Open-Source Goodness: NocoDB is open-source, which means you can tweak, twist, and tailor it however you like. Plus, you get to benefit from a community of folks constantly improving it. Airtable? It's cool, but it doesn't give you that level of freedom.

Wallet-Friendly: With NocoDB, you can dodge those monthly fees by hosting it yourself. Airtable's got a free tier, but if you want more records, views, or fancy features, you'll need to shell out some cash.

Your Data, Your Rules: Since you can self-host NocoDB, you're in the driver's seat when it comes to your data. You decide where it's stored and who gets to peek at it. With Airtable, your data's hanging out on their servers.

Cons of NocoDB compared to Airtable:

User-Friendly Vibes: Airtable's super intuitive. Its interface is clean, and setting up bases feels like a breeze. NocoDB, being a bit newer, might take a tad more time to get used to.

Template Treasure Trove: Airtable's got a ton of templates. Whether you're planning an event, tracking inventory, or managing projects, there's probably a template for that. NocoDB's still building up its collection.

Built-In Integrations: Airtable plays well with others, offering a bunch of built-in integrations with popular apps. While NocoDB is expanding its integration game, it's not quite at Airtable's level yet.

If you're a fan of open-source, love having control over your data, and are looking to save some bucks, NocoDB might be right up your alley. But if you're after a tool that's super user-friendly, has a rich template library, and easily connects with other apps, Airtable's still holding strong.

The Grand Conclusion

In the constant evolving world of digital tools, there's always a balance to strike between the established giants and the innovative newcomers. Whether it's design platforms, scheduling tools, or database systems, each offers its unique strengths and potential drawbacks.

Open-source alternatives like Penpot, Cal.com, NocoDB, and others bring to the table unparalleled customisation, cost savings, and data control. On the flip side, established players like Figma, Calendly, and Airtable offer user-friendly interfaces, extensive integration options, and the reliability that comes with time and refinement.

Who says you have to pick a side?

The beauty of today's tech ecosystem is that you can mix and match. Use an open-source tool for one task and a proprietary one for another. It's like having a Swiss Army knife combined with a specialized toolkit. You get the best of both worlds.

For instance, you might love the customization of NocoDB for your database needs but prefer the seamless integrations of Calendly for scheduling. Or perhaps the open-source flexibility of Penpot appeals to your design side, while the reliability of Slack keeps your team communication smooth.

The point is, you're not boxed into one category. It's all about finding the right tool for the job and sometimes, that means blending the open-source spirit with the polished experience of proprietary software.

So, as you venture into the tech realm, remember: it's not about choosing sides. It's about finding the perfect tools that make your digital life easier, efficient, and enjoyable. Dive in, experiment, and craft your unique tech mosaic!

Support our own Open-Source project on Github

We're on a journey to become a favourite project for developers, and while we're still in the building phase, we would love it, if you'd consider starring us on GitHub 🌟: https://github.com/rigdev/rig

Edit: 2023-09-14 - Updated "Cons of Brave compared to Google Chrome" and the Conclusion after feedback from @stretch07

Our Team's Favourite Open Source Projects Right Now

Niklas — Tue, 12 Sep 2023 13:38:13 +0000

At Rig.dev, we love open source. It's not just about writing code; it's about sharing solutions, solving problems - all as a community. We asked everyone on our team to show their current favourite open source project. Why? Because we're always on the hunt for cool tools and we thought you might be too.

The answers we got are all over the map, and that's what makes this so interesting. Some of us are into hardcore frameworks, while others are vibing with smaller, simpler projects that solve everyday challenges. Either way, we're stoked about these open source projects that are making our lives easier and we think you might find a few new favourites in this list too.

A humble favor 🤗:

I'm on a mission to reach 1k stars for Rig.dev. Would you consider supporting by giving it a star on Github? It encourages me and the rest of the team to produce new, high-quality content weekly.

Our Github: https://github.com/rigdev/rig

OpenTofu - Benjamin

“It is important that the main tool used for IaaC truly is OSS.”
Benjamin, Senior Software Engineer

OpenTofu (formerly known as OpenTF) is a fork of Terraform, an open-source infrastructure as code (IaC) tool that allows you to safely and efficiently build, change, and version infrastructure. OpenTofu is still under development, but it aims to be a fully open-source, community-driven alternative to Terraform.

The origin of OpenTofu is the Terraform OSS community's concern over HashiCorp's decision to switch the Terraform license from the Apache 2.0 license to the Business Source License (BSL). The BSL is a more restrictive license that could make it more difficult for organizations to use Terraform in certain circumstances.

Website: https://opentofu.org/
Github: https://github.com/opentofu/manifesto

bpython - Matias

“It is much nicer to use than the built-in python interpreter.”
Matias, Software Engineer

bpython is a Python interpreter with a fancy curses interface. It adds several features common to IDEs, such as syntax highlighting, expected parameter list, auto-indentation, and autocompletion. It is released under the MIT License.

bpython was created by David Paleino in 2004. The original goal of bpython was to provide a more interactive and user-friendly experience than the standard Python interpreter. bpython has since become a popular choice for Python developers, and is used by a wide range of people, from beginners to experienced professionals.

Website: https://www.bpython-interpreter.org
Github: https://github.com/bpython/bpython

Llama 2 - Christian

“In the spirit of open sourcing modern technologies, and removing the veil of mystery from large language models, i think it is worth mentioning Llama 2 - Meta’s newest large language model that they have open sourced”
Christian, Founding Engineer

Llama 2 is an open-source, large language model (LLM) developed by Meta AI Research. It is a collection of pretrained and fine-tuned LLMs ranging in scale from 7 billion to 70 billion parameters. The fine-tuned LLMs, called Llama 2-Chat, are optimized for dialogue use cases.

Website: https://ai.meta.com/research/publications/llama-2-open-foundation-and-fine-tuned-chat-models/
Github: https://github.com/facebookresearch/llama

Vue 3 + Nuxt - Nicky

“I've worked with multiple JS frameworks, but my go-to is Vue, combined with Nuxt. I love the simplicity of it! It has a gentle learning curve that allows developers to quickly grasp the fundamentals and start building applications. Nuxt.js, on the other hand, provides a solid structure and conventions for building Vue applications, making it easier to organize your codebase. Besides that, the performance is great, and the reactivity system is just world class.”
Nicky, Frontend Tech Lead

Vue.js is a progressive JavaScript framework for building user interfaces. It is designed to be incrementally adoptable and can be used to build anything from simple single-page applications to complex enterprise applications.

Nuxt.js is a framework that builds on top of Vue.js to make it easier to create server-rendered applications. It provides a number of features, such as built-in routing, state management, and templating, that make it easy to create SEO-friendly and performant applications.

Vue
Website: https://vuejs.org
Github: https://github.com/vuejs/core

Nuxt
Website: https://nuxt.com
Github: https://github.com/nuxt

Open Foundry - Jack

“Open-foundry has always been a great resource for unique and interesting fonts that I can experiment with.”
Jack, Designer

Open Foundry is a website that curates and distributes open-source fonts. It was founded in 2020 by a group of designers and developers who wanted to make it easier for people to find and use high-quality open-source fonts. Open Foundry has a catalog of over 1,000 fonts, all of which are free to download and use.

The fonts are carefully curated by the Open Foundry team to ensure that they are of high quality and meet the needs of a variety of users. In addition to providing a catalog of fonts, Open Foundry also offers a blog, forum, and knowledge base that provide resources for designers, developers, and anyone else who wants to use open-source fonts.

Website: https://open-foundry.com

Dub.co - Thor

“I like how Steven is working in public and how fast he moves. This has, together with a range of other projects, inspired us to launch earlier than what feels comfortable to maximise the amount of feedback we can get from the community at the current stage.”
Thor, Co-founder

Dub is an open-source link management tool for modern marketing teams to create, share, and track short links. It was created by Steven Tey in 2022 and is currently used by over 1,000 companies.

Dub solves the problem of long, clunky URLs by shortening them into more memorable and shareable links. It also provides detailed analytics on link clicks, so marketers can track the performance of their campaigns.

In addition to shortening links, Dub also allows users to create custom domains, add UTM parameters, and set expiration dates for links. It also integrates with other popular marketing tools, such as Google Analytics and Salesforce.

Website: https://dub.co
Github: https://github.com/steven-tey/dub

Responsivel App - Swastika

“I use it while working on frontend projects. It previews all the target screens side-by-side. Pretty convenient while testing/debugging.”
Swastika, Developer Advocate

Created by a team of web developers who were frustrated with the lack of good tools for responsive web development, Responsively App wanted to create a tool that would make it easy for web developers to test their websites on a variety of devices and screen resolutions.

Responsively App allows developers to preview web pages on a variety of devices, emulate different screen resolutions and aspect ratios, zoom in and out of web pages, take screenshots, and share web pages with others.

Website: https://responsively.app
Github: https://github.com/responsively-org/responsively-app

Medusa - Niklas

“I’ve previously worked with various platforms such as Shopify, Magento and Woocommerce (Wordpress) and none of them checked all the boxes. Medusa seems like a very promising platform, and I'm excited to see how it develops in the future.”
Niklas, Growth Lead

MedusaJS is an open-source commerce platform that provides a set of modular building blocks for building rich, reliable, and performant commerce applications. It is designed to be flexible and future-proof, with MIT-licensed modules that give developers full control over their commerce stack.

MedusaJS was created by a team of developers who were frustrated with the limitations of traditional commerce platforms. They wanted to create a platform that would be easy to use, scalable, and adaptable to the needs of businesses of all sizes.

Website: https://medusajs.com
Github: https://github.com/medusajs/medusa

Support our own Open-Source project on Github

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

What's your favourite Open-Source project? Share yours! 🚀

4 Open-Source Technologies Every True Full-Stack Developer Should Master

Niklas — Mon, 11 Sep 2023 15:48:48 +0000

Full-stack development is a constantly evolving, dynamic field with new tools and technologies. Developers often find themselves in pursuit of the best resources to streamline their workflow and build exceptional applications. From the frontend user interface to the backend server logic and all the data management in between, the task can seem daunting, and using the right set of tools makes all the difference. There are multiple frameworks and tools with different capabilities for every part of full-stack applications, and choosing the proper set helps simplify and streamline the development process.

A humble favor 🤗:

I'm on a mission to reach 1k stars for Rig.dev. Would you consider supporting by giving it a star on Github? It encourages me and the rest of the team to produce new content weekly.

https://github.com/rigdev/rig

In this article, we'll explore a powerful set of open-source frameworks and tools that can be a go-to option for a number of applications when building fully functional, full-stack projects.

The 4 technologies that we will discuss in this article are:

React.js for Frontend Development
Golang for Backend Development
PostgreSQL for the Database layer
Rig.dev for DevOps/Deployment

DevOps/Deployment has been added to expand the role of a full-stack developer within the entire development lifecycle.

Frontend with Reactjs

React.js, developed and maintained by Meta (formerly Facebook), is an open-source JavaScript library for building user interfaces. React's component-based architecture sets it apart, which allows developers to break down user interfaces into reusable and encapsulated components. This approach fosters modular development and efficient rendering.

One of the great things about Reactjs is its popularity and community support. One will find a wealth of resources, tutorials, and third-party libraries to enhance your React projects, and it's also one of the most versatile front-end frameworks.

Use Cases and Examples

Single-Page Applications (SPAs): React's component-based architecture is perfect for building SPAs, where dynamic content updates are essential.
Progressive Web Apps (PWAs): React can create PWAs that provide a native app-like experience in the browser.
Interactive User Interfaces: React simplifies the development of complex UIs with interactive elements, such as forms, dashboards, and real-time data displays.

Benefits of React.js:

Component-Based Architecture: React's component-based approach encourages code reusability and maintainability by breaking user interfaces into reusable building blocks.
Virtual DOM: React's virtual DOM minimizes browser updates, resulting in faster performance and a smoother user experience.
One-Way Data Flow: React's unidirectional data flow simplifies data management and enhances application predictability and testability.

Backend with Golang

Go, often referred to as Golang is an open-source, statically typed programming language created by Google. While not a traditional backend framework, Go is known for its efficiency, simplicity, and robust standard library, making it an excellent choice for building server-side applications.

Primary Functionalities

Concurrency: Go's built-in concurrency primitives, like goroutines and channels, make writing highly concurrent and efficient backend code easy.
Networking: Go provides robust networking support, making it suitable for building network-related applications, including network protocols, servers, and clients.
Web Frameworks: Go has web frameworks like Gin and Echo that simplify building robust web services with routing, middleware support, and more.

Benefits of Golang:

Simplicity and Readability: Go's clean and minimalistic syntax promotes code readability and reduces unnecessary complexity. It encourages good coding practices and makes code easier to understand and maintain.
Concurrency Support: Go provides built-in support for concurrency with goroutines and channels, making it efficient for concurrent and parallel programming.
Strongly Typed and Statically Checked: It is statically typed, which means variable types are checked simultaneously, ensuring code reliability and reducing runtime errors.
Cross-Platform Compatibility: Go is highly portable and compiles machine code, allowing developers to create cross-platform applications for various operating systems.

Database layer with PostgreSQL

PostgreSQL, often called Postgres, is an open-source relational database management system (RDBMS) known for its reliability and extensibility. It supports various data types, including JSON, and offers advanced features such as indexing, replication, and partitioning.

It is an ancient database management system and can be integrated with programming languages like Java, C, C++, etc. This feature allows developers to have customized functions.

Features of PostgreSQL:

ACID Compliance: PostgreSQL is fully ACID-compliant, ensuring data integrity and reliability, even in complex transactional scenarios.
Advanced Indexing: PostgreSQL provides various indexing methods, including B-tree, hash, and GiST (Generalized Search Tree), allowing developers to optimize queries for multiple data types.
Concurrency Control: PostgreSQL can handle concurrent access because of its Multi-Version Concurrency Control (MVCC) system. This means that multiple users can access and modify data without conflicts.

Benefits of using PostgreSQL:

Rich features and extensions: Robust features of PostgreSQL, like Multi-Version Concurrency Control (MVCC), recovery, granular access controls, tablespaces, asynchronous replication, nested transactions, and a refined query planner/optimizer make it stand out from other databases.
Reliability and standards compliance: The large base of open source contributors lends it a built-in community support network. It's highly fault-tolerant, and since it's an ancient db, troubleshooting is also easy.
Easy to use: You only need a little training before getting your hands dirty on PostgreSQL. It's pretty easy to learn.

DevOps/Deployment on Kubernetes with Rig.dev

Kubernetes has become the de facto standard for how modern companies scale their applications. Developers interact with Kubernetes in one of two ways: either they are exposed to Kubernetes themselves either natively through something like Helm and Terraform, or they are working with an abstraction layer that takes control of the entire cluster, leaving no room to go out of the box without fragile external dependencies.

While the former gives flexibility for complex solutions, it enforces a high learning curve with no abstractions. The latter, on the other hand, removes the flexibility that is often needed when scaling or building complex solutions.

This is where Rig.dev comes into the picture!

Rig.dev is an open-source application platform for Kubernetes, designed to eliminate its inherent complexities. It seeks to empower developers with a developer-friendly deployment engine that simplifies rolling out, managing, debugging, and scaling applications on Kubernetes. With features like Capsules and Rollouts, a slick Dashboard, and a CLI for terminal operations, Rig.dev aims to provide developers with powerful and intuitive tools.

Rig.dev is not just another platform; it's the vision for the future of application development. It promises an application platform that evolves with your needs, all while ensuring the freedom to choose and transition between any cloud provider that supports Kubernetes.

Features of Rig.dev:

Capsules: Rig.dev comes with a deployment engine that wraps resources in what we call Capsules. A Capsule contains a bundle of resources that will be deployed as a unit.
Rollouts: Deployments of a build to a specific environment and network configuration. Rollouts are immutable and are used to manage the lifecycle of the application.
Dashboard and CLI compatible: Rig.dev provides a Dashboard that easily lets developers work with Application resources and the CLI where all operations are available.

Benefits of Rig.dev:

Capsules and Rollouts are modern takes on developer-friendly abstractions.
Deploy well-configured applications in Kubernetes without the complexity.
CI/CD pipelines that seamlessly integrate with GitHub Actions.
Having both Dashboard and CLI increases the development experience.

We'd love your support

We are not done building yet, but we would love your support on Github.

Also, please join our Slack Community to share feedback, report bugs, suggest features, and stay tuned for future updates.

Build from Scratch vs. Developer Platforms

Niklas — Thu, 07 Sep 2023 14:03:46 +0000

Developers face multiple challenges when building and deploying robust applications to the cloud. Choosing between building everything from scratch or using a managed platform for developers can significantly impact scalability, complexity, and timeline.

In this article, we will look at the factors to consider when selecting the right frameworks and platforms to build and deploy backend applications to the cloud.

Factors to consider when selecting what platform to build on

Deployment Simplicity: How easy is it to deploy applications? Platforms that simplify deployment, especially those tailored for Kubernetes, can be invaluable.
Kubernetes Integration: Given the dominance and capabilities of Kubernetes in the cloud ecosystem, it's crucial to consider how seamlessly a platform integrates with it.
Flexibility vs. Structure: Does the platform offer the flexibility to design your application architecture, or does it impose a specific structure?
Scalability and Performance: The platform should scale with your application's growth, ensuring consistent performance irrespective of user demand.
Open-Source Foundations: Platforms built on open-source technologies, like Kubernetes, offer more control and reduce vendor lock-in risks.

Ways to build backends

Generally, there are two prominent approaches to building backend applications and deploying them to the cloud:

Building from scratch: Building the backend application and infrastructure environment from scratch. Developers are responsible for everything, from design, code, test, etc.
Choosing between BaaS or PaaS providers: Building applications on top of a Backend-as-a-Service or Platform-as-a-Service provider. Developers don't need to code every feature or set up complex infrastructure while building the backend.

These platforms provide pre-built backend services and infrastructure, allowing developers to focus more on application-specific logic and frontend development. However, they come with certain limitations, such as constraints in customization, integration challenges, and potential vendor lock-in risks.

Building from scratch

When developers opt to build from scratch, they're diving deep into the realm of granular control and customization. This approach demands:

Application Frameworks: Selecting the right programming language, frameworks, and protocols tailored to the backend application's needs.
Infrastructure Choices: Making decisions about deployment strategies and scaling mechanisms. With the rise of container orchestration, many developers are now considering Kubernetes as their go-to for deployment, given its flexibility and scalability.

While this method offers unparalleled customization, it's a challenging path. The complexities of design, coding, testing, and maintenance often offset the allure of complete control. Moreover, while powerful, the intricacies of Kubernetes require a steep learning curve and expertise.

Let's look at the Pros and Cons of Building from Scratch

Pros

Complete Customization: Developers have full control over every aspect of the backend architecture. This level of customization is ideal for projects with complex requirements.
Ownership and Independence: Developers have complete ownership of the codebase and infrastructure. Organizations are not reliant on third-party services, reducing the risk of vendor lock-in.

Cons

Time-Consuming: Building from scratch requires significant development time as developers must design, develop, and test every component of the backend application.
Expertise in multiple skills required: Creating a robust and scalable backend demands skilled developers with expertise in various technologies and databases.
Code Maintenance: Developers are responsible for all the ongoing maintenance and updates, adding to long-term development costs.
High Development Cost: As everything is developed and maintained by the development team, organizations have to spend potentially higher for specialized skills and third-party tools.

Choosing between already existing platforms

Already existing platforms for building the backend alleviate the pressure of building and managing everything independently. Developers don't need to code every single feature or infrastructure. Hence, they can focus more on streamlining the development and deploying fast.

BaaS platforms offer pre-built backend services and infrastructure, allowing developers to sidestep some of the complexities of backend development. However, they can sometimes limit customization and flexibility, especially for projects with unique requirements.

PaaS platforms provide a more comprehensive environment for development and deployment in the cloud. They offer greater control over the infrastructure but might require developers to grapple with the complexities of platforms like Kubernetes.

Pros and cons of using a BaaS provider

Pros:

Rapid Development: BaaS platforms come with pre-built backend services, enabling developers to develop and deploy applications quickly.
Documentation: Popular BaaS solutions like Firebase and Supabase often have extensive documentation, simplifying integration with front-end applications.

Cons:

Limited Customization: While BaaS platforms offer convenience, they might not cater to projects with unique requirements, especially those that benefit from Kubernetes' scalability and flexibility.
Vendor Lock-In: Relying heavily on a specific BaaS platform can lead to dependency, making migrations challenging.
Scalability Concerns: While BaaS platforms are convenient, they might not be optimal for projects with high scalability demands, especially compared to Kubernetes-based solutions.

Pros and Cons of Using a PaaS Provider

Pros:

Reduced Infrastructure Overheads: PaaS solutions minimize the need for managing on-premises infrastructure, leading to cost savings.
Kubernetes Integration: Many modern PaaS platforms now offer Kubernetes integrations, allowing developers to leverage its scalability and flexibility without diving deep into its complexities.

Cons:

Initial Complexity: PaaS platforms, especially those centered around Kubernetes, can have a steep learning curve. Developers must familiarize themselves with the platform's ecosystem, APIs, and constraints.
Backend Feature Development: Unlike BaaS, PaaS solutions might not offer essential backend features out-of-the-box. Developers need to build these or integrate third-party solutions.
Provider Dependency: Committing to a specific PaaS can lead to dependency on its services and features, potentially complicating future migrations.
Vendor Lock-In Risks: Utilizing unique features of a PaaS can lead to vendor lock-in, making transitions to other platforms or solutions challenging.

Which platform to choose?

The rise of Kubernetes has reshaped the application development landscape. Its scalability, flexibility, and robustness promise has made it a cornerstone for many modern applications. However, with its power comes complexity, leading developers to seek platforms that simplify its intricacies without compromising its capabilities.

Platforms like Vercel and Netlify have revolutionized development in the frontend domain by offering streamlined workflows, automated deployments, and seamless framework integrations. They've set a benchmark for what developers expect from platforms regarding ease of use and efficiency.

The backend world, however, presents its own set of challenges. Traditional BaaS solutions, while convenient, might offer more scalability and flexibility than Kubernetes-centric projects demand. On the other hand, PaaS solutions, even the few that integrate with Kubernetes, can sometimes introduce unnecessary complexities that hinder rapid development.

So, what's the ideal solution?

Enter Rig.dev

We are currently building in the process of building Rig.dev - an open-source application platform for Kubernetes, designed to eliminate its inherent complexities. We seek to empower developers with a developer-friendly deployment engine that simplifies the process of rolling out, managing, debugging, and scaling applications on Kubernetes. With features like Capsules and rollouts, a slick Dashboard, and a CLI for terminal operations, Rig.dev aims to provide developers with powerful and intuitive tools.

Rig.dev is not just another platform; it's our vision for the future of application development. It promises an application platform that evolves with your needs, all while ensuring the freedom to choose and transition between any cloud provider that supports Kubernetes.

We are not done building yet, but we would love your support on Github along the way 🙏

Also, please join our Slack to share feedback, report bugs, and suggest features.

Introducing Rig.dev: An open-source application platform for Kubernetes

Niklas — Tue, 05 Sep 2023 13:46:38 +0000

Kubernetes is a bitter pill to swallow for most application developers. Here's some background on how we came to spend most of our waking hours on trying to diminish the complexity, our opinion on the biggest problem of Kubernetes, and our take on how to solve it with an opinionated approach and carefully chosen abstractions.

Rig.dev at a glance

Rig.dev offers an open-source application platform for Kubernetes. We empower developers with our developer-friendly deployment engine that simplifies the process of rolling out, managing, debugging, and scaling applications on Kubernetes.

Born out of frustrations

We come from various backgrounds but have all seen the immense pain of scaling applications. We have built internal developer platforms, Kubernetes operators at scale, and even a Kubernetes alternative. Through those journeys, we've seen how Kubernetes often suffers from being misunderstood and mishandled in how developers are exposed to it, which 10 out of 10 times slows development teams by causing unnecessary complexity.

We've taken all of the learnings, especially the frustrations from this, and turned it into Rig.dev, where we believe we are on a path to solve most of the frustration you get from building, and especially scaling, applications on Kubernetes in large production environments.

Developers struggle to work with Kubernetes

Developers interact with Kubernetes in one of two ways: either they are exposed to Kubernetes themselves either natively through something like Helm and Terraform, or they are working with an abstraction layer that takes control of the entire cluster, leaving no room to go out of the box without fragile external dependencies. While the former gives flexibility for complex solutions, it enforces a high learning curve with no abstractions. The latter, on the other hand, removes the flexibility that is often needed when scaling or building complex solutions.

Additionally, developers are left with an environment where local development is a secondary consideration. Local reproducibility, fast development cycles, and a local setup that mimics production is nothing but a dream at most companies.

Both issues make Kubernetes a technology that leaves developers with mixed feelings - it's a fantastic technology when it all just works, but an overwhelming burden when you have to go one step deeper.

Introducing Rig.dev

At Rig.dev, we are passionate about fixing these issues. We want developers to shine in this environment and feel empowered by what Kubernetes has to offer.

We believe we have assembled the right team to build out true abstractions that serve the developers while also respecting DevOps and their role in defining the infrastructure. Abstractions like Capsules, Rollouts and Builds, that are intuitive for developers and lower the friction both at day one, but also through scaling the team and the product.

We want companies to be able to pick Rig.dev, without having to reconsider which cluster provider to use or have to start off with a migration; it can live in and alongside your existing platform tooling. Building the right infrastructure is a hard thing to do, and building a product that puts no restrictions on your solution while guiding novices to use the platform "correctly", is, in our opinion, the best offering we can bring.

Developers are always at the center of everything we do, and we are only satisfied with Rig.dev once developers building applications for Kubernetes are just as spoiled as Frontend developers are with technologies such as Vercel and Netlify.

So, what exactly do we leave you with?

As with any developer-focused product, it's about providing the right tools to do the job. Rig bundles with a

→ A modern take on developer-friendly abstractions; our Capsules & Rollouts.

→ A slick Dashboard that easily lets you work with your Application resources

→ A CLI where all operations are available for the developers that are more comfortable with the terminal.

→ A solid foundation from which we can build and continuously ship new features and improvements

→ A team that are eager to learn how we can make the product even better, either directly or through our community

Get involved & show your support

We're overwhelmed by all the support we've received so far — from our investors, network, and the developers we've talked with — and can't wait to see what the next generation of cloud-native developers and companies will achieve with Rig.dev.

We would appreciate it if you support us with a star on GitHub and help spread the word about Rig.dev to show your support!

We'll actively seek feedback, bug reports, and feature requests in our Rig.dev Community – so please join us here!

We raised a $2.2M pre-seed round for our open-source application platform for Kubernetes

Niklas — Mon, 04 Sep 2023 18:26:30 +0000

Announcing our pre-seed round

We're excited to announce that we've raised a $2.2 million pre-seed round – one of the largest ever in Denmark - to enable fast-moving development teams to build and scale applications on Kubernetes. The round is led by byFounders - a leading Nordic early-stage VC - with participation from TinyVC, Dreamcraft, NP-Hard Ventures, The Nordic Web, and a group of notable angel investors.

"We are excited by their take on how to rethink developer platforms by carefully choosing the right abstraction layers and introducing workflows and automations that eliminates the complexity of building and scaling application without causing platform lock-in and limiting developers. On top, we are impressed by the team - not only their level of ambition but also how well the two founders complement each other in terms of skills" - Martin Krag, Partner at byFounders.

Launching an open-source application platform for Kubernetes
After months of user research, designing, and developing, we are now emerging from stealth and launching Rig.dev - The open-source application platform for Kubernetes.

With Rig.dev we empower developers to work in their own environments with elevated application abstractions, while still leveraging Kubernetes's reliability, portability, and scalability. Our developer-friendly deployment engine simplifies the process of rolling out, managing, debugging and scaling applications. On top, we provide foundational APIs for user management, authentication, storage, and database integrations. The platform includes a Dashboard, CLI, and CI/CD pipelines that seamlessly integrate with GitHub Actions.

Why we started Rig.dev

We have experienced the immense power of platforms like Kubernetes in streamlining infrastructure management. However, through firsthand experience, we have seen how such technologies often suffer from being misunderstood and underutilized.

Additionally, too many developers are wasting valuable time reinventing generic and repetitive features and infrastructure environments - we've been there ourselves.

We founded Rig.dev to rethink the developer platform landscape by eliminating the complexities associated with building, deploying, and managing applications on Kubernetes at scale.

We want to empower developers in fast-moving companies to focus on engineering that matters - without locking them into a specific vendor or restricting them in what technologies they can use to build their product. In short, we are building the solution that we always wanted ourselves.

What the future holds

We couldn't be more excited about the future at Rig.dev. Every day we see the need for what we're building, and we can't wait to get our platform in the hands of as many development teams as possible.

We've got ambitious plans in store as we've entered the second half of 2023. Our roadmap is packed with value-adding features that we will release quickly throughout the rest of 2023.

Get involved & show your support

We're overwhelmed by all the support we've received so far — from our investors, network, and the developers we've talked with along the way — and can't wait to see what the next generation of cloud-native developers and companies will achieve with Rig.dev.

We are currently locked in on improving and distributing Rig.dev.Therefore, we would appreciate it if you could leave a star on GitHub and help spread the word about Rig.dev to show your support!

We'll actively seek feedback, bug reports, and feature requests in our Rig.dev Community – so please join us here!