DEV Community: Mohit Nagaraj

I Built an Open-Source Visual Kubernetes Orchestration Platform — No YAML Required

Mohit Nagaraj — Wed, 08 Apr 2026 02:49:08 +0000

If you've ever stared at a 400-line Kubernetes YAML file at 2am trying to figure out why your service can't reach its database, this post is for you.

I'm a founding engineer, I kept running into the same problem: Kubernetes is incredibly powerful, but it's also brutally complex to get right. The learning curve is steep, the feedback loop is slow, and one wrong indent breaks everything.

So I built KubeOrch — an open-source visual orchestration platform that lets you design, connect, and deploy Kubernetes workloads through a drag-and-drop interface. No YAML. No guessing. Just draw your architecture and hit deploy.

Here's what I built, how it works under the hood, and why I open-sourced the whole thing.

The Problem With Kubernetes Today

Kubernetes has won the container orchestration wars. It's the de facto standard. But the developer experience hasn't caught up with its adoption.

Consider what it takes to deploy a simple web app with a PostgreSQL database and a Redis cache on Kubernetes:

A Deployment manifest for your app
A Service to expose it
A Deployment + PersistentVolumeClaim for Postgres
A Service for Postgres
A Secret for credentials
A Deployment for Redis
A Service for Redis
A ConfigMap for environment variables
An Ingress with TLS config
NetworkPolicies if you care about security

That's 9+ YAML files, hundreds of lines, and dozens of ways to silently misconfigure something. And this is the simple case.

The tools that exist today — Helm, Kustomize, Lens — either abstract the YAML (but you still write it) or visualize existing clusters (but you still write it first). No one has tackled the core issue: the mental model of a distributed system is visual, but the tooling forces you to express it as text.

What KubeOrch Does

KubeOrch flips the workflow. Instead of writing manifests and hoping they wire up correctly, you:

Drag services onto a canvas (Postgres, Redis, Kafka, your app — 150+ components)
Connect them by drawing lines between ports
Deploy — KubeOrch generates the manifests, resolves dependencies, and applies them to your cluster

The platform has four main components:

1. KubeOrch Core (Go)

The brains of the operation. A Go API server built on Gin that handles:

JSON-to-YAML transformation — your visual design is stored as a JSON graph internally; Core converts it to production-ready Kubernetes manifests at deploy time
Automatic connection resolution — when you draw a line from your app to Postgres, Core figures out the right DATABASE_URL env var, the right service DNS name, the right port — without you specifying any of it
Nixpacks integration — point Core at a GitHub repo and it builds a container automatically, no Dockerfile needed
Service mesh support — Istio, ingress controllers, and load balancers are first-class citizens
Real-time streaming — WebSocket-based log and metrics streaming from all running containers

// Example: Core's auto-wiring picks up connection intent and resolves it
type Connection struct {
    SourceService string `json:"source"`
    TargetService string `json:"target"`
    SourcePort    int    `json:"sourcePort"`
    TargetPort    int    `json:"targetPort"`
}
// Core resolves this into env vars, DNS entries, and NetworkPolicies automatically

2. KubeOrch UI (Next.js + TypeScript)

The visual canvas, built with:

React Flow for the drag-and-drop workflow designer
Next.js 15 with TypeScript
shadcn/ui + Tailwind CSS v4 for the component library
Zustand for state management
WebSocket for real-time log streaming

The UI is intentionally opinionated. Services snap together intelligently — when you try to connect a Node.js app to PostgreSQL, the UI already knows what that connection means and pre-fills the configuration.

3. OrchCLI (Go)

A CLI that handles the local dev loop:

# Initialize a KubeOrch project
orchcli init

# Start all services (supports hot reload)
orchcli start

# Fork and contribute to core or UI
orchcli init --fork-core
orchcli init --fork-ui

It supports concurrent operations with file locking to prevent config corruption, auto-detects your dev mode based on which repos you've cloned, and handles hot reload across all services.

Install it in one line:

curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

Or via npm:

npm install -g @kubeorch/cli

4. Docs (Astro)

Full documentation site covering architecture, getting started, CLI reference, and API reference — built with Astro for fast static generation.

The Architecture Decision I'm Most Proud Of

The hardest problem in building KubeOrch wasn't the UI or even the Kubernetes API integration — it was automatic service wiring.

When two services are connected in the visual canvas, the platform needs to figure out:

What environment variable should carry the connection string?
What DNS name should the dependent service use?
What port should be exposed?
Does this connection need a NetworkPolicy?
Does it need a Secret, or is the connection string safe to put in a ConfigMap?

The naive solution is to ask the user. But that defeats the whole point.

The solution I landed on is a service template system with typed ports. Every component in the library (Postgres, Redis, Kafka, etc.) is defined with its ports annotated with type metadata:

{
  "name": "postgresql",
  "ports": [
    {
      "port": 5432,
      "type": "postgres",
      "envVarTemplate": "{{TARGET_NAME}}_DATABASE_URL",
      "valueTemplate": "postgresql://{{USER}}:{{PASSWORD}}@{{SERVICE_DNS}}:5432/{{DB_NAME}}"
    }
  ]
}

When you draw a connection, Core matches port types, renders the templates with resolved values, and injects the result as environment variables into the dependent service — with a Secret for anything sensitive.

150+ services are defined this way, covering databases, queues, ML platforms, monitoring stacks, and more.

Why Open Source?

I could have built this as a SaaS. I thought about it.

But Kubernetes tooling lives and dies by community trust. Operators don't want their cluster credentials going through a third-party API. They want to run the control plane themselves, audit the code, and contribute fixes.

More importantly — the problems KubeOrch solves are universal. Every team fighting with YAML is fighting the same fight. An open-source project that solves this well becomes infrastructure for the entire ecosystem.

KubeOrch is Apache 2.0 licensed and structured as a CNCF-aspiring project with full governance documentation:

Contributor ladder (from contributor → member → maintainer)
Governance policy
API stability policy
RFC/proposal process in the community repo

The goal is to eventually donate this to the CNCF sandbox. The groundwork is already laid.

Getting Started

Try it locally

# Install the CLI
curl -sfL https://raw.githubusercontent.com/KubeOrch/cli/main/install.sh | sh

# Initialize a new project
orchcli init

# Start everything
orchcli start

Open http://localhost:3001 to see the visual canvas.

Run Core directly

git clone https://github.com/KubeOrch/core.git
cd core
go mod tidy
go run main.go

Core starts at http://localhost:3000.

Explore the repos

KubeOrch/core — Go backend, orchestration engine
KubeOrch/ui — Next.js visual canvas
KubeOrch/cli — OrchCLI developer tool
KubeOrch/community — Governance, roadmap, RFCs
KubeOrch/docs — Full documentation

What's Next

The roadmap has three near-term priorities:

GitOps integration — sync your visual design to a Git repo and trigger deploys on push
Multi-cluster support — manage workloads across multiple clusters from one canvas
Plugin SDK — let the community build and publish custom components to the marketplace

If any of these problems interest you, the contributor guide is in the community repo and issues are open.

Closing Thoughts

Kubernetes isn't going anywhere. But the developer experience has a long way to go before it matches the power of the underlying platform.

KubeOrch is my attempt to close that gap — to make the visual mental model of distributed systems the primary interface, not a second-class visualization layer bolted on top of YAML.

If you've felt the pain of Kubernetes configuration, give it a try. And if you want to help build it, the doors are open.

GitHub: github.com/KubeOrch

Follow me on X/Twitter for more.

Building a Kubernetes Operator in Go with Kube-Shift

Mohit Nagaraj — Mon, 14 Jul 2025 03:49:48 +0000

Kubernetes has become the de-facto standard for container orchestration. As its adoption grows, so does the need for extending its capabilities to manage complex, stateful applications. This is where Kubernetes Operators come in. In this article, we'll explore how to build a custom Kubernetes Operator from scratch using Go and the controller-runtime library. We'll use kube-shift, a custom operator for database schema migrations, as a real-world example to guide us through the process. You can check out more blogs here: blog

The "Why": What Problem Do Operators Solve?

Before we dive into the code, let's understand the problem operators solve. Managing applications on Kubernetes often involves more than just deploying a set of pods. Many applications require complex lifecycle management, including installation, upgrades, and handling failures. Operators automate these tasks by extending the Kubernetes API with Custom Resource Definitions (CRDs) and a custom controller to manage them.

The kube-shift project is a perfect example. It introduces a DatabaseMigration resource to Kubernetes, allowing you to manage database schema changes as part of your deployment process, just like any other Kubernetes resource.

Setting the Stage: Project Scaffolding with Kubebuilder

The kube-shift operator, like many Go-based operators, is built using the Kubebuilder framework. Kubebuilder provides a set of tools to quickly scaffold a new operator project, including the boilerplate for CRDs, controllers, and other necessary components.

The entry point of our operator is cmd/main.go. This file is responsible for setting up and running the controller manager.

// cmd/main.go
package main

import (
    // ... imports
    "github.com/mohit-nagaraj/kube-shift/api/v1alpha1"
    "github.com/mohit-nagaraj/kube-shift/internal/controller"
    // ...
)

func main() {
    // ... flag parsing and setup

    mgr, err := ctrl.NewManager(ctrl.GetConfigOrDie(), ctrl.Options{
        // ... options
    })
    if err != nil {
        setupLog.Error(err, "unable to start manager")
        os.Exit(1)
    }

    if err = (&controller.DatabaseMigrationReconciler{
        Client: mgr.GetClient(),
        Scheme: mgr.GetScheme(),
    }).SetupWithManager(mgr); err != nil {
        setupLog.Error(err, "unable to create controller", "controller", "DatabaseMigration")
        os.Exit(1)
    }

    // ...
}

Here, we create a new manager and register our DatabaseMigrationReconciler with it. The manager is responsible for running the controller and managing its lifecycle.

Defining Our Custom Resource: The `DatabaseMigration` CRD

The first step in creating our operator is to define the custom resource it will manage. This is done in api/v1alpha1/databasemigration_types.go. This file defines the Go types that represent our DatabaseMigration CRD.

// api/v1alpha1/databasemigration_types.go
package v1alpha1

import (
    metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
)

// DatabaseMigrationSpec defines the desired state of DatabaseMigration
type DatabaseMigrationSpec struct {
    Database  DatabaseConfig  `json:"database"`
    Migration MigrationConfig `json:"migration"`
}

// DatabaseMigrationStatus defines the observed state of DatabaseMigration
type DatabaseMigrationStatus struct {
    Phase   MigrationPhase `json:"phase,omitempty"`
    Message string         `json:"message,omitempty"`
}

// +kubebuilder:object:root=true
// +kubebuilder:subresource:status

// DatabaseMigration is the Schema for the databasemigrations API
type DatabaseMigration struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   DatabaseMigrationSpec   `json:"spec,omitempty"`
    Status DatabaseMigrationStatus `json:"status,omitempty"`
}

The DatabaseMigration struct embeds metav1.TypeMeta and metav1.ObjectMeta, which are common to all Kubernetes objects. The Spec field defines the desired state of our resource, while the Status field represents its current state.

The Heart of the Operator: The Controller and Reconciliation Loop

With our CRD defined, we need a controller to act on it. The controller's logic is implemented in internal/controller/databasemigration_controller.go. The core of the controller is the Reconcile function. This function is called every time a DatabaseMigration resource is created, updated, or deleted.

// internal/controller/databasemigration_controller.go

// DatabaseMigrationReconciler reconciles a DatabaseMigration object
type DatabaseMigrationReconciler struct {
    client.Client
    Scheme *runtime.Scheme
    Log    logr.Logger
    // ... other fields
}

// +kubebuilder:rbac:groups=database.mohitnagaraj.in,resources=databasemigrations,verbs=get;list;watch;create;update;patch;delete
// ... other rbac markers

func (r *DatabaseMigrationReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
    log := r.Log.WithValues("databasemigration", req.NamespacedName)

    // your logic here

    return ctrl.Result{}, nil
}

The Reconcile function receives the name and namespace of the DatabaseMigration resource that triggered the event. It's the reconciler's job to fetch the resource and take the necessary actions to bring the system to the desired state defined in the resource's Spec. This could involve creating jobs, pods, or other resources to perform the database migration.

Advanced Reconciliation: Beyond the Basics

A robust operator does more than just create resources. kube-shift demonstrates several advanced concepts:

Status Updates: The controller updates the Status field of the DatabaseMigration resource to reflect the current state of the migration. This provides valuable feedback to users.
Finalizers: To ensure graceful cleanup, kube-shift uses a finalizer. The DatabaseMigrationFinalizer is added to the resource on creation. This prevents the resource from being deleted until the controller has performed any necessary cleanup tasks.
Leader Election: In a high-availability setup, you might run multiple instances of your operator. Leader election ensures that only one instance is active at a time, preventing conflicts. This is configured in cmd/main.go.

Testing Your Operator

Testing is crucial for any production-grade software. kube-shift includes both unit and integration tests.

Unit Tests: These tests focus on individual components of the operator in isolation.
Integration Tests: The project uses the envtest package to run integration tests against a real Kubernetes API server. You can see this in internal/controller/suite_test.go, which sets up a test environment for the controller tests.

Conclusion

Building a Kubernetes Operator is a powerful way to extend Kubernetes and automate complex application management tasks. By leveraging tools like Kubebuilder and controller-runtime, you can create robust, production-ready operators. The kube-shift project is an excellent example of how to apply these concepts to solve a real-world problem.

To learn more, I encourage you to explore the kube-shift repository on GitHub. You'll find the complete source code, along with more details on how to build, deploy, and use the operator. Happy coding!

GhostPass: Anonymous Wallet Verification

Mohit Nagaraj — Sun, 01 Jun 2025 09:23:53 +0000

GhostPass is a privacy-focused Web3 application built during the Monad Hackathon that enables anonymous wallet verification without revealing any personal identity. This post covers the project goals, architecture, features, and implementation details.

📝 Prefer a personal behind-the-scenes read? Check out my 3-min blog post covering our hackathon experience in detail.

🧠 About the Monad Hackathon

The Monad Web3 Hackathon brought together blockchain developers, builders, and privacy advocates to experiment on top of Monad, a high-performance, EVM-compatible Layer 1 blockchain. Monad is designed for 10,000+ TPS, and its innovative consensus and execution engine enables scalable dApps without compromising decentralization.

During the hackathon, our team built GhostPass — a privacy-first wallet verification platform — within 6 hours.

Project: GhostPass

GhostPass is a privacy-focused platform for anonymous wallet verification on the blockchain. It allows users to prove wallet ownership and display verification status—without revealing personal identity.

🔐 Key Features

Wallet Verification: Users sign a challenge to prove ownership of their wallet.
Anonymous Identity: No personal data is collected; only public blockchain information is stored.
Verification Lookup: Anyone can check verification status of any Ethereum wallet.
Batch & Revoke Support: Admin tools for bulk verification and revoking.
Modern Web Interface: Built with Next.js and TypeScript for a smooth user experience.

⚙️ How It Works

1. Connect & Verify

Users connect via MetaMask or any EIP-1193 wallet.
A message challenge is signed to prove ownership.
Signature is verified server-side.
On success, a verification transaction is submitted to the smart contract.
The wallet address, verification timestamp, and transaction hash are logged.

2. Display Verified Users

The backend maintains a list of verified wallets with:
- address
- verifiedAt timestamp
- transactionHash
This data is accessible via:
- Public API (/verified-users)
- UI-based lookup interface

3. Check Verification Status

Anyone can check if a wallet is verified by querying:
- /verify/:address

🛠️ Technology Stack

Frontend: Next.js (React), TypeScript
Backend: Node.js, Express, ethers.js
Smart Contracts: Ethereum via Hardhat
Wallet Integration: MetaMask or any EIP-1193-compatible wallet

📡 API Overview

Endpoint	Method	Description
`/verify`	POST	Verify wallet by submitting signature
`/verify/:address`	GET	Check if a wallet is verified
`/verified-users`	GET	List all verified wallets
`/revoke`	POST	Admin-only endpoint to revoke verification

🧪 Local Development Setup

Backend


bash
cd backend
npm install
# Set environment variables in .env
npm start

Leading My First Hackathon Team

Mohit Nagaraj — Tue, 20 May 2025 17:10:00 +0000

From Building a Smart Triage Assistant to a Rainy Midnight Walk.

Every once in a while, an experience transforms how we see ourselves - not just as developers, but as people. For me, that moment happened during a 24-hour hackathon. This post is a reflection of what my team built, the journey of leading a team for the first time, and a story of a midnight rainwalk that I'll never forget.

The Problem We Tackled

The hackathon challenge centered around improving healthcare access and efficiency. According to the World Health Organization, 70% of patients experience delays in triage - a critical step in emergency and primary care. These delays stem from overburdened staff, lack of accessibility in remote areas, and non-intelligent response systems. We wanted to change that.

Our Solution: SnapAid

Our project, SnapAid, is a Smart Triage Assistant powered by multimodal AI. The assistant supports voice, text, and image inputs to quickly assess patient symptoms and generate urgency recommendations. The platform also includes a personalized health quiz, automatic tagging of cases (like "urgent" or "infection"), and real-time notifications to doctors for high-risk scenarios. The idea was simple: empower users with fast, intelligent, and accessible healthcare insights.

Taking the Lead

This hackathon was also my debut as a team leader. I was nervous. I didn’t know if I could plan, delegate, or even inspire my team well. I started by organizing planning sessions, listing priorities, and trying to keep everyone in sync. Despite the initial hesitation, I realized that leadership isn't about knowing everything - it's about listening, learning, and helping others do their best.

Out of our group, only one teammate truly synced with my rhythm. While others couldn't fully coordinate due to various reasons, this one teammate stayed committed throughout the event. Together, we brainstormed, debugged, and pushed through challenges. Her presence turned this into more than just a coding sprint—it became a shared journey.

First All-Nighter

Some moments are etched into memory forever. It was past midnight, and we stepped out into the drizzle after hours of coding. The streets were empty. We walked, talked about code, life, and how crazy this all felt. Caffeine-fueled, sleep-deprived, but so alive. That short walk under the rain meant more to me than any milestone—it was clarity, connection, and comfort. I particularly told her to not put water on me, but no use T-T.

Let me be clear, I wasnt awake for anything for the whole night up until now T-T. I used to sleep at own hackathons i used to go. This was also my first time staying up an entire night just for a project. No sleep, just code, good food, and teamwork. There’s something magical. Gotta agree tho, it was exhausting, yes—but equally exhilarating.

The Demo & Reaction

Our pitch went well. We demoed the multimodal triage assistant, explained the tech stack, and showcased real-time alerts. Some of the judges were intrigued. Others seemed rushed. It wasn’t the standing ovation I secretly hoped for, but I knew we had built something real.

Now comes the honest part. Some teams had clearly been working on their projects long before the event started. Others used ChatGPT to generate huge codebases, including structured tables straight from AI—and it showed. Somehow, those got selected. It felt like the raw, sleepless hustle of the moment went unnoticed. Only the devs who stayed up and built it from scratch understood the true grind.

Despite everything, I wouldn't trade this night for anything. The coding, the chaos, the connection—it was one of the most memorable experiences of my developer journey. Just two teammates, fueled by ambition, caffeine, and the joy of building something from nothing.

If you’ve ever led a team, pulled an all-nighter for a hackathon, or felt invisible amidst the crowd—share your story. And tell me: how do we keep hackathons fair, inspiring, and real?

Our Unforgettable Journey: Winning Innerve 9 Hackathon at AIT Pune

Mohit Nagaraj — Wed, 12 Feb 2025 16:29:40 +0000

(This is going to be a very long read! If you're short on time, check out this LinkedIn post for a quick update.)

The Beginning of an Adventure

It all started on the 5th of the month, when our team—Bhuvan M, Mohit Nagaraj, Naman Parlecha, Vivek Agarwal, and I—set out on an unforgettable journey from Bangalore to Pune. We had booked bus tickets, and for me, it was the first time traveling solo to a place I had never been before. The anticipation was high, but so were the challenges.

At the bus station, I almost fell victim to a scam when some strangers tried to ask me for money. Meanwhile, our teammate Bhuvan had a close call—he nearly missed the bus☠️! Just as it was about to leave, he ran and managed to hop on, barely making it in time. The ride itself was grueling; I felt nauseous and restless🤢, unable to sit still for long😭. Eventually, I managed to eat dinner and sleep through most of the 16-hour journey.

When we finally reached Maharashtra, the first thing we ate was Poha🥗—a light and delicious breakfast, which felt perfect for a morning meal. Still exhausted, we dozed off again until we reached Pune, albeit 2 hours behind schedule.

A Warm Welcome at Army Institute of Technology

As soon as we stepped onto the AIT campus, we were greeted with an incredibly warm welcome. The decorations, the enthusiasm of the organizers, and the discipline of the students left a deep impression on me. The respect and courtesy displayed by the students made me emotional🥹—it was a stark contrast to what I was used to.

After a swift check-in, we roamed around the campus before being taken to our hostel. Once settled in, we immediately got to work. The first step was ideation—we scoured through various strategies online and refined our plan for the hackathon⚡. This preliminary groundwork would prove invaluable in helping us execute efficiently the next day.

Dinner time arrived, and the hospitality continued. Volunteers personally escorted us to the canteen, where I had my first-ever experience with mess food. It was simple yet delicious, and we made sure to eat to our hearts’ content ❤️.

Later that night, an unexpected moment of doubt hit us. A random participant approached us and claimed that his team had already built hardware worth ₹6 lakhs☠️. It seemed unfair💔, considering the hackathon rules explicitly stated that everything had to be built within 24 hours. At first, we felt disheartened, fearing that we stood no chance against such resources. ~~However, we later found out that the judges were already aware of the situation.~~ I decided to sleep early, conserving energy for the big day ahead.

The Hackathon Begins!

The next morning, I woke up at 8 AM to the bustling atmosphere of a hostel filled with participants preparing for the challenge. My teammates were still asleep—classic😂! Eventually, only Naman and I made it to the inauguration on time, while the others strolled in later.

With the formalities out of the way, we had breakfast, refueled ourselves, and prepared for battle🔫🪖. The hackathon venue was perfect—the reading area was air-conditioned, and when we requested to move to a quieter spot, the mentors readily agreed🙌. We set up in the back, a comfortable corner where we could focus without distractions.

As soon as the event kicked off, we worked in structured time blocks, setting clear hourly deadlines. The initial hours flew by as we made rapid progress, leveraging our familiarity with the technologies. Before we knew it, lunchtime had arrived, and we were astonished at how four hours had passed in the blink of an eye.

By dinner, most of our components— "both frontend and backend" —were complete. The real challenge now lay in integration. After dinner, we took a short break, enjoying the mesmerizing night sky🌃✨ before heading back into grind mode.

As midnight approached, the number of participants still actively working started to dwindle📉. Many had given in to exhaustion, but we pushed through. Debugging, testing, and integrating our platform was no easy feat🔥. There were moments of frustration when things didn't work, but we persevered, iterating over and over until everything clicked into place🥲.

The Final Stretch and Presentation

By early morning, we had completed our project, but the work wasn’t over yet. Some of our team members crashed from sheer exhaustion, while the rest of us shifted focus to creating our presentation and demo video. Before we knew it, the 10 AM deadline had arrived, and the submissions closed.

At this point, I had intended to do some internship work but ended up dozing off instead😴. When I woke up, I learned that we had been selected for the final presentation round! We hurried downstairs🏃‍♂️💨, where we had the opportunity to showcase our project to the judges. Their reactions were incredible—they were genuinely impressed by our AI-driven multimedia EdTech platform, Synapse💻. It felt amazing to explain our vision to people who truly understood and appreciated its impact🥹.

Connecting with so many brilliant minds at AIT was an unforgettable experience, especially as a first-year student with entrepreneurial ambitions. We had made it to the final round, and the anticipation was at an all-time high.

The Moment of Truth

The prize distribution ceremony began in the evening. Our hearts pounded as we waited for the results😖

The announcement for third place came—it wasn’t us. A wave of uncertainty hit us. We knew from experience that if you don’t place second or third, first place is often a long shot. When second place was announced and it still wasn’t us😔 — we felt a mix of disappointment and acceptance.

Then, the final announcement came 🔥WE WON🔥!

Hearing our team’s name called as the Grand Prize winners was a surreal moment. The flood of emotions—excitement, pride, disbelief—was overwhelming🎉. We walked onto the stage to receive our prize of ₹1.25 Lakh from a senior general, basking in the glory of our hard work and dedication.

A Lasting Memory

That night, we were utterly exhausted. As soon as we returned to our hostel, we collapsed into bed💤, unable to process everything that had happened. The next day, we stayed in Pune to explore the city, taking in its beauty, culture, and energy🥹. It was soo nice to see the city's vibes and people there. It was the perfect way to end such an incredible journey. Loved the entire expirience❤️

Returning home on the 11th morning, I felt a profound sense of happiness and accomplishment. This experience was more than just winning a hackathon—it was about pushing limits, learning, growing, and creating memories that will last a lifetime.

To anyone aspiring to participate in such events, my advice is simple:

Believe in your vision, trust your team, and never underestimate the power of perseverance.

This journey has shaped me in ways I never imagined, and I can't wait to see where our next adventure takes us! 🚀

🌟 Hacktoberfest 2024 Reflection 🌟

Mohit Nagaraj — Sat, 12 Oct 2024 16:42:57 +0000

This year, Hacktoberfest was a game-changer for me! 🎉 It gave me the perfect opportunity to dive into the world of open-source, and I haven’t looked back since.

Starting out with my first PR in CSS felt like a great way to get my feet wet, and from there, things took off. My second PR was a TypeScript challenge, and then I stepped into even more complex projects in Go and Ruby for my third and fourth contributions. 💪

I can honestly say that Hacktoberfest is what helped me kickstart my open-source journey and taught me how to work on real-world projects. It's been an amazing experience, learning new languages and tackling challenges I didn’t think I could! 🚀

Feeling super grateful for the opportunity to contribute and grow. Thank you, Hacktoberfest, for helping me get started! 🙌 #Hacktoberfest #OpenSource #Growth #TechJourney #ProudContributor