Biryani CSS Art — India's Soul in Every Grain 🍛

Nitish Pandey — Sat, 08 Aug 2026 05:37:58 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

I chose to build a classic Dum Biryani — the ultimate comfort food! 🍛
There is nothing quite like opening a steaming handi of biryani and seeing the rich, saffron-colored rice dotted with fried onions, mint, and spices. It's a dish that brings people together and feels like a warm hug, making it the perfect inspiration for the Comfort Food challenge.

Demo

Here is my CSS Art representation of a traditional Biryani Handi!
I built this primarily using vanilla CSS to create the realistic clay texture of the pot, the individual grains of rice, the steam animations, and the garnishes. I added a tiny bit of JavaScript just for a subtle mouse-parallax tilt effect and a saffron sparkle when you click the pot.

https://github.com/pandeynitish23/dev_css_chalange/
https://dev-css-chalange.nitishkumar-nk-np.workers.dev/

Journey

Building this was a really fun exercise in CSS gradients and positioning!
What I'm most proud of:

The Clay Handi: I used layered radial and linear gradients along with inset box shadows to give the pot a realistic, 3D clay texture with lighting highlights.
The Rice & Garnishes: Creating individual rice grains, mint leaves, and onion crisps using CSS border-radius and positioning was tedious but incredibly rewarding when it all came together.
The Atmosphere: Adding animated steam and floating background spice particles helped bring the scene to life and make it feel hot and fresh. It was a great challenge keeping the JavaScript minimal and relying on pure CSS for the heavy lifting of the art itself!

How I Update Applications in an AWS Auto Scaling Group Using Golden AMIs

Nitish Pandey — Sat, 08 Aug 2026 05:08:05 +0000

Introduction

If you've ever managed applications running in an Amazon EC2 Auto Scaling Group, you've probably wondered what's the safest way to deploy updates without manually logging into every instance.

Over the last few months, I've been using a --Golden AMI-- approach for application deployments. It has made deployments much more consistent, easier to roll back, and reduced the chances of configuration drift.

In this article, I'll share the process I follow.

Why I Prefer Golden AMIs

There are many ways to deploy applications on EC2.

You can SSH into instances and update them manually, but over time that creates inconsistencies because every server ends up slightly different.

Instead, I update one EC2 instance, verify everything, create a new AMI, and let the Auto Scaling Group launch new instances from that image.

That way every instance is identical.

Step 1 – Prepare a Working EC2 Instance

I usually follow one of these approaches:

Detach an EC2 instance from the Auto Scaling Group without reducing the desired capacity.
Or launch a temporary EC2 instance from the current production AMI.

This gives me a safe environment to make changes without affecting live traffic.

Step 2 – Deploy the Changes

Once connected to the instance, I:

Pull the latest application code
Update configuration if needed
Restart the application
Verify the application starts correctly

For example:

git pull origin main

sudo systemctl restart myapp

Step 3 – Verify Everything

Before creating an AMI, I always make sure:

The application is running
APIs respond correctly
Services are healthy
Logs don't show unexpected errors

It's much better to spend a few extra minutes testing than discover a problem after every instance has been updated.

Step 4 – Create a Golden AMI

After everything looks good, I create a new AMI from the updated instance.

I also use a meaningful naming convention such as:

myapp-prod-v2

This makes future deployments and rollbacks easier to manage.

Step 5 – Update the Launch Template

Next, I create a new Launch Template version using the new AMI and set it as the default version.

Now the Auto Scaling Group knows which image should be used for new instances.

Step 6 – Start an Instance Refresh

This is probably my favorite part because AWS handles most of the work.

The Auto Scaling Group:

Launches a new instance
Waits for health checks
Terminates one old instance
Repeats until every instance has been replaced

The deployment happens gradually, so users aren't affected.

Step 7 – Final Checks

Once the refresh finishes, I verify:

Target Group health
CloudWatch metrics
Application functionality
Auto Scaling Group status

If everything looks good, I terminate the temporary EC2 instance.

What If Something Goes Wrong?

One of the biggest benefits of this approach is how easy rollback becomes.

I simply change the Launch Template back to the previous version and start another Instance Refresh.

AWS gradually replaces the instances with the previous working AMI.

Final Thoughts

This is the deployment process I've found most reliable for applications running on EC2 Auto Scaling Groups. It keeps deployments consistent, reduces manual work, and makes rolling back much less stressful when something doesn't go as planned.

I'm always interested in learning different approaches, so if you manage applications on EC2, how do you handle deployments? Do you use Golden AMIs, CodeDeploy, containers, or something else?

DEV Community: Nitish Pandey