I wanted to bring those activities into one application.

That idea became RideMatch AI — a full-stack vehicle discovery platform that combines a searchable vehicle catalogue, AI-assisted recommendations, comparison features, and a containerized application architecture.

This article explains the application, the engineering decisions behind it, and the DevOps practices I implemented around it.

1. What is RideMatch AI?

RideMatch AI allows users to explore vehicles, filter them by preferences, compare specifications, and receive AI-assisted recommendations.

The application includes:

• Vehicle discovery and filtering
• AI-assisted recommendations
• Vehicle comparison
• JWT authentication
• Favorites
• Automotive news integration
• Fuel cost calculation
• Dashboard statistics

The technology stack consists of Next.js, React, Node.js, Express, PostgreSQL, Google Gemini, Docker, Docker Compose, GitHub Actions, AWS, and Terraform.

2. Application architecture

I separated the application into three main layers:

Frontend: Next.js and React provide the user interface.

Backend: Node.js and Express handle API requests, business logic, authentication, and integrations.

Database: PostgreSQL stores vehicle catalogue information and application data.

Gemini and the news API are external integrations used by the backend.

flowchart TD
    User --> Frontend[Next.js Frontend]
    Frontend --> API[Express Backend]
    API --> DB[(PostgreSQL)]
    API --> Gemini[Gemini API]
    API --> News[News API]

This separation keeps UI concerns, API logic, and persistent data responsibilities distinct.

3. Designing the recommendation engine

One of the important engineering decisions was not to rely entirely on an LLM to select vehicles.

Instead, I used a hybrid approach.

First, the backend applies SQL filters to identify eligible vehicles. Then a deterministic scoring model ranks the candidates:

Gemini is then used to provide recommendation explanations or re-rank candidate IDs. The backend validates the response and falls back to deterministic ranking if the AI output is invalid.

This design keeps recommendations connected to actual database records while still using AI to improve the user experience.

4. Building the application with Docker

I containerized the frontend and backend using Docker.

The project includes multi-stage Docker builds. The frontend uses the Next.js standalone output, while the backend uses a multi-stage Node.js build.

Docker Compose coordinates the frontend, backend, and PostgreSQL services.

This makes it easier to run the application consistently across development and deployment environments.

5. Implementing CI/CD with GitHub Actions

I added GitHub Actions workflows to automate several stages of the delivery process.

The configured pipeline includes:

1. Source changes trigger the CI workflow.
2. Frontend and backend build steps run.
3. Terraform formatting and validation are performed.
4. Docker images are built.
5. Trivy scans container images.
6. Images are published.
7. SonarCloud analysis runs.
8. A separate deployment workflow connects to an EC2 host and uses Docker Compose to update the application.

An important limitation: automated application test coverage is not yet implemented. The Trivy workflow also needs stronger failure gates for security findings.

The goal is to keep improving the pipeline rather than treating a successful build as proof that the application is production-ready.

6. AWS and Infrastructure as Code

I worked on Terraform configuration for an AWS environment involving:

• VPC and subnet design
• Internet and NAT gateways
• Security groups
• Application Load Balancer
• EC2 launch template
• Auto Scaling Group
• IAM configuration
• CloudWatch configuration

The Terraform code has validation evidence. I distinguish that from a current Terraform-managed production deployment, which is not verified.

This distinction matters: infrastructure code, successful validation, and deployed infrastructure are three different things.

7. Kubernetes and monitoring

The repository also contains Kubernetes manifests, Helm templates, and monitoring-related configuration.

These represent additional implementation work and areas under development. The Helm chart has outstanding issues, and the monitoring stack has not been verified as a complete deployed environment.

My next steps are to make the Kubernetes deployment installable, verify the resource dependencies, and deploy observability components end to end.

8. Challenges and lessons

A few lessons from this project:

AI should not replace deterministic application logic. Filtering and scoring candidates before asking an LLM for explanations gives the system a more controlled foundation.

Containerization is only one part of deployment. Images, environment configuration, networking, database connectivity, and deployment verification all matter.

A CI pipeline is not automatically a quality gate. Builds and scans are useful, but tests and failure conditions are necessary.

Infrastructure configuration is not proof of infrastructure deployment. Terraform validation does not mean the architecture is running in AWS.

Operational troubleshooting matters. Understanding application health, service dependencies, ports, logs, and database connectivity is as important as writing deployment configuration.

9. What's next?

The next improvements I want to work on include:

• Automated backend and frontend tests
• Stronger CI security gates
• More robust deployment and rollback handling
• A fully verified Kubernetes deployment
• End-to-end Prometheus and Grafana monitoring
• Improved per-user favorites and data isolation
• Live fuel-price integration

Conclusion

RideMatch AI started as a vehicle discovery application and grew into a project where I could work across frontend development, backend APIs, databases, AI integration, Docker, CI/CD, and cloud infrastructure.

The most valuable part was understanding how these components connect — and learning to distinguish between code that exists, workflows that have been tested, and systems that are actually deployed.

GitHub: https://github.com/Ashwin1808/ridematch-ai

I'd welcome technical feedback, especially around the recommendation architecture, deployment workflow, and infrastructure design. </WritingBlock}

4. LinkedIn project announcement

🚀 Introducing RideMatch AI — An AI-Powered Vehicle Discovery Platform

I recently worked on RideMatch AI, a full-stack application designed to simplify vehicle discovery, comparison, and personalized recommendations.

The project combines application development with practical DevOps implementation.

What I built:

• Vehicle discovery and advanced filtering
• AI-assisted recommendations using Google Gemini
• Vehicle comparison and favorites
• JWT authentication
• PostgreSQL-backed application
• Automotive news integration
• Fuel cost calculator

Technology stack:

Next.js | React | Node.js | Express.js | PostgreSQL | Gemini AI | Docker | Docker Compose | GitHub Actions | AWS | Terraform | Trivy | SonarCloud

DevOps implementation:

• Multi-stage Docker builds
• Docker Compose orchestration
• CI/CD workflows using GitHub Actions
• Container image scanning with Trivy
• SonarCloud integration
• AWS EC2 deployment using Docker Compose
• Terraform-based AWS infrastructure configuration

I also explored Kubernetes, Helm, and monitoring configurations as part of the project's ongoing improvements.

One of my biggest takeaways was understanding that building an application is only one part of the job. Packaging it, automating delivery, managing infrastructure, troubleshooting failures, and verifying deployments are equally important.

🔗 GitHub: https://github.com/Ashwin1808/ridematch-ai

#DevOps #AWS #Docker #GitHubActions #Terraform #NodeJS #NextJS #PostgreSQL #CICD #CloudComputing #FullStackDevelopment #AI

I wanted to explore that complete workflow through a practical project rather than learning each DevOps tool in isolation.

So, I built a Task Manager application and worked on connecting its application architecture with containerization, CI/CD automation, Kubernetes, Helm, and GitOps.

In this article, I'll walk through the architecture, tools, implementation, and what I learned while building the project.

Project Architecture:

Before exploring the individual tools, let's understand how the different components of this project fit together.

The application uses a frontend, backend, and database architecture. Docker packages the application components, CI/CD automates the build and image publishing process, and Kubernetes provides the orchestration layer. Helm manages the Kubernetes configurations, while Argo CD is configured to manage deployments using GitOps.

Application Stack:

The application follows a three-tier architecture with a frontend, backend, and database.

Frontend – React and Vite

The frontend provides the user interface for managing tasks. It is built using React and Vite and packaged into a Docker image.

Backend – Java 21 and Spring Boot

The backend handles application logic and API requests. It is built with Spring Boot and communicates with the PostgreSQL database.

Database – PostgreSQL 16

PostgreSQL stores the application's task data. It runs as a separate service in the containerized application setup.

Local Development – Docker Compose

Docker Compose brings the application services together, making it easier to run and test the stack locally.

1. Project Overview: Two Repositories, One Application

I organized this project into two separate GitHub repositories to maintain a clear separation between application development and deployment configuration.

Repository 1: Task Manager Application

GitHub: https://github.com/Ashwin1808/Demo-Tasts

This repository contains the application code and the workflows used to build and package it.

Technology stack:

• Frontend: React and Vite – provides the user interface.
• Backend: Java 21 and Spring Boot – handles application logic and API requests.
• Database: PostgreSQL 16 – stores application data.
• Containerization: Docker – packages the frontend and backend into container images.
• Local environment: Docker Compose – runs the application services together.
• CI/CD: GitHub Actions and Jenkins – provides automated build and image publishing workflows.
• Container registry: GitHub Container Registry (GHCR) – stores the application images.

The main objective of this repository is to manage application development, containerization, and CI/CD automation.

Repository 2: Task Manager GitOps

GitHub: https://github.com/Ashwin1808/task-manager-gitops

The second repository manages the Kubernetes deployment configuration separately from the application source code.

Technology stack:

• Kubernetes: Manages the application workloads.
• Helm: Packages and organizes Kubernetes resources into a reusable chart.
• Argo CD: Configured to monitor the GitOps repository and synchronize deployment configurations.
• Gateway API: Defines traffic routing to the frontend and backend services.
• ConfigMaps and Secrets: Manage application configuration and sensitive deployment values.
• PersistentVolumeClaim: Defines persistent storage for PostgreSQL.
• Horizontal Pod Autoscaler: Configures automatic backend replica scaling based on CPU utilization.
• Terraform: Defines an S3 bucket using a LocalStack-compatible endpoint for infrastructure-as-code practice.

The GitOps repository keeps deployment configuration version-controlled and independent of application source code.

How Both Repositories Work Together

The overall workflow connects application development with deployment configuration:

1. Application code is maintained in the Task Manager repository.
2. CI/CD workflows build and publish container images to GHCR.
3. The GitOps repository contains the Helm chart and Kubernetes deployment configurations.
4. Argo CD is configured to monitor the GitOps repository.
5. Kubernetes resources are rendered through Helm and can be synchronized by Argo CD when the required cluster components are available.

This separation makes the application code and deployment configuration easier to maintain independently.

Important: The Helm chart passed lint validation and successfully rendered 13 Kubernetes resources. This confirms the configuration validation, not a completed live Kubernetes deployment.

Containerization and CI/CD Automation:

Containerizing the Application with Docker

I used Docker to package the application components into container images, making them easier to run consistently across environments.

The application consists of three main components:

• Frontend: React and Vite application.
• Backend: Java 21 and Spring Boot application.
• Database: PostgreSQL 16.

Docker Compose is used to define and run the application services together during local development.

Automating Builds with GitHub Actions

I used GitHub Actions to automate the application build and container image publishing workflow.

The pipeline is designed to:

1. Retrieve the application source code.
2. Build the application components.
3. Build Docker images.
4. Publish the images to GitHub Container Registry (GHCR).

This reduces repetitive manual work and provides a consistent image-building workflow.

Jenkins CI/CD

I also worked with Jenkins to implement an alternative CI/CD pipeline.

Working with both GitHub Actions and Jenkins helped me understand different approaches to pipeline configuration and automation.

Container Image Management

The application images are published to GitHub Container Registry.

The GitOps repository references these images using versioned image tags, allowing the deployment configuration to specify which application image should be used.

This connects the application build process with the deployment configuration maintained separately in the GitOps repository.

Kubernetes, Helm and GitOps with Argo CD:

Deploying the Application with Kubernetes

I organized the Kubernetes resources in the Task Manager GitOps repository to manage the frontend, backend, and PostgreSQL components.

The configuration includes:

• Deployments: Define the frontend, backend, and PostgreSQL workloads.
• Services: Provide internal communication between application components.
• ConfigMaps: Store backend application configuration.
• Secrets: Provide database credentials to the backend.
• PersistentVolumeClaim: Requests persistent storage for PostgreSQL.
• Horizontal Pod Autoscaler: Configures backend scaling based on CPU utilization.

The backend HPA is configured with a minimum of 2 replicas, a maximum of 5 replicas, and a target CPU utilization of 70%.

Packaging Kubernetes Resources with Helm

Instead of maintaining the deployment resources as unrelated YAML files, I organized them into a Helm chart.

The chart includes templates for:

• Frontend Deployment and Service
• Backend Deployment and Service
• PostgreSQL Deployment, Service and PVC
• ConfigMap and Secret
• Backend Horizontal Pod Autoscaler
• Gateway, GatewayClass and HTTPRoute

I validated the chart using Helm:

helm lint ./helm/task-manager

The lint command completed successfully with zero failures.

I also rendered the Kubernetes manifests:

helm template task-manager ./helm/task-manager \
  --namespace task-manager

The command successfully rendered 13 Kubernetes resources.

GitOps Workflow with Argo CD

I created an Argo CD Application manifest in the GitOps repository.

It references the GitHub repository and uses the Helm chart located at:

helm/task-manager

The Argo CD Application is configured with:

• Automated synchronization
• Automatic pruning
• Self-healing
• Namespace creation

This configuration allows Argo CD to use Git as the source of truth for the desired deployment configuration.

The configuration is committed to GitHub, making deployment changes version-controlled and reviewable.

Traffic Routing with Kubernetes Gateway API

I also added Kubernetes Gateway API resources to define how incoming traffic should reach the application services.

The configuration includes:

• GatewayClass: References the Envoy Gateway controller.
• Gateway: Defines the HTTP listener on port 80.
• HTTPRoute: Defines routing rules for application traffic.

The HTTPRoute sends:

• /api traffic to the backend service on port 8080.
• / traffic to the frontend service on port 8080.

The Gateway API CRDs and compatible controller must be installed in the Kubernetes cluster before these resources can operate.

This setup demonstrates how application deployment and traffic routing configuration can be maintained together in the GitOps repository.

Infrastructure as Code with Terraform:

I included Terraform in the GitOps repository to practice defining infrastructure through code.

The Terraform configuration defines an S3 bucket using an AWS provider configured with a LocalStack-compatible endpoint.

The configuration includes:

• AWS provider configuration
• Region variables
• S3 bucket resource
• Resource tags
• Terraform dependency lock file

The configuration is intended for LocalStack-compatible testing rather than claiming a live AWS deployment.

This helped me understand how infrastructure resources can be declared, managed, and version-controlled using Terraform.

Configuration Validation:

During the project, I used command-line validation to check the deployment configuration.

Helm lint

helm lint ./helm/task-manager

Result: 1 chart linted, 0 charts failed.

Helm template rendering

helm template task-manager ./helm/task-manager \
  --namespace task-manager

Result: Successfully rendered 13 Kubernetes resources.

These checks helped identify configuration issues before attempting deployment to a Kubernetes cluster.

Key Learnings and Challenges:

Building this project helped me understand how different DevOps tools fit into a complete application delivery workflow.

Some of my key learnings were:

• Separating application source code from deployment configuration using two Git repositories.
• Building and publishing container images through CI/CD workflows.
• Organizing Kubernetes manifests into reusable Helm charts.
• Understanding GitOps principles and Argo CD synchronization.
• Configuring Gateway API resources for frontend and backend routing.
• Defining infrastructure resources through Terraform.
• Validating Helm configurations before deployment.

One important lesson was that successful configuration validation does not automatically mean a workload has been deployed successfully. Live cluster validation is a separate step.

What's Next?:

This project is an ongoing learning journey. My next focus is to move beyond configuration validation and work toward a complete deployment in a Kubernetes environment.

Some of the areas I plan to explore further include:

• Deploying the application to a Kubernetes cluster.
• Validating the complete Argo CD synchronization workflow.
• Configuring and testing Gateway API traffic routing.
• Improving monitoring and observability with Prometheus and Grafana.
• Exploring AWS infrastructure and cloud deployment.

My goal is to keep improving the project while documenting the practical challenges and lessons along the way.

Project Repositories

I've maintained two separate repositories to keep the application code and deployment configurations organized.

1. Application Repository

Contains the application source code, Docker configuration, and CI/CD pipeline setup.

https://github.com/Ashwin1808/Demo-Tasts

2. GitOps Repository

Contains Kubernetes manifests, Helm charts, Argo CD configuration, Gateway API resources, and Terraform configuration.

https://github.com/Ashwin1808/task-manager-gitops

Both repositories are available publicly for anyone interested in exploring the implementation.