Loading…
Articles about technology trends, software, platforms, tools, engineering, and innovation.
June 4, 2026
From GitHub to Production: Deploying a Next.js Website on AWS Most developers start by deploying websites to platforms like Vercel or Netlify. They're fantastic tools, and for many projects they're exactly the right choice. But sooner or later, every developer becomes curious about what happens behind the scenes. Recently, I set up a complete production deployment pipeline for a client project using AWS. The goals were simple: Keep hosting costs low Own the entire infrastructure Automate deployments Deliver content globally through a CDN The final architecture turned out to be surprisingly elegant: No servers. No SSH. No manual uploads. Every merge to the main branch automatically deploys the latest version of the website. Why AWS Instead of Vercel? This isn't about replacing Vercel. In fact, Vercel is often the best option for many projects. However, for this project I wanted full ownership of the infrastructure, hands-on AWS experience, minimal recurring hosting costs, and a deployment pipeline I completely understood. For a mostly static website, Amazon S3 and CloudFront make an excellent combination. Building a Static Next.js Website The website was built using Next.js. Since the project consisted primarily of informational pages, there was no need to run a Node.js server. Next.js supports static exports through: Running npm run build generates an out directory containing everything required to serve the website without a backend server. Hosting the Website in Amazon S3 The first instinct many developers have is to make the S3 bucket public. That approach works, but it's no longer considered best practice. Instead, the bucket remains private. Only CloudFront is granted permission to access the bucket. Direct access to S3 is blocked entirely. This architecture improves security while still allowing the website to be served publicly. Adding CloudFront CloudFront sits in front of S3 and acts as the public entry point. It provides: Global content delivery HTTPS support Edge caching Lower latency Better performance After creating the distribution, AWS generates a CloudFront domain which immediately serves the website globally. Connecting a Custom Domain The domain for this project was managed through Hostinger. The process involved: 1. Creating an SSL certificate in AWS Certificate Manager (ACM) 2. Verifying domain ownership through DNS records 3. Attaching the certificate to CloudFront 4. Updating DNS records to point to the CloudFront distribution A Lesson Learned the Hard Way CloudFront only supports ACM certificates created in the us-east-1 region. I initially created the certificate in Mumbai, saw it was successfully issued, and assumed everything was ready. CloudFront disagreed. After recreating the certificate in N. Virginia (us-east-1), everything worked perfectly. It's one of those AWS details that's easy to miss until you encounter it yourself. Automating Deployments with GitHub Actions The final piece of the puzzle was automation. The workflow looked like this: Once configured, deployment became incredibly simple. No FTP. No dragging files into S3. No logging into AWS. Just merge and ship. What I Learned This project taught me several valuable lessons: S3 buckets do not need to be public. CloudFront should be the only public entry point. ACM certificates for CloudFront must be created in us-east-1. GitHub Actions can completely automate deployments. Static websites can be hosted extremely cheaply on AWS. AWS infrastructure becomes far less intimidating once you build something real with it. Final Architecture Final Thoughts There's something satisfying about understanding every part of your deployment pipeline. While platforms like Vercel make deployment incredibly easy, building the stack yourself teaches you how modern web infrastructure actually works. For company websites, landing pages, blogs, documentation sites, and many SaaS frontends, a combination of Next.js, GitHub Actions, Amazon S3, and CloudFront provides a fast, secure, scalable, and cost-effective deployment solution. The best part? Once everything is set up, deployment disappears into the background and you can focus entirely on building features.
June 5, 2026
Deploying a Next.js Website to Amazon S3 with GitHub Actions and CloudFront Introduction Managing deployments manually becomes tedious as projects grow. For my Next.js website, I wanted every push to the main branch to automatically build the application, upload the latest static files to Amazon S3, and invalidate the CloudFront cache so users immediately receive the newest version. The result is a simple CI/CD pipeline powered by GitHub Actions, AWS S3, and CloudFront. Architecture Overview Why This Approach? This setup provides several advantages: | Benefit | Description | |----------|-------------| | Automated Deployments | Every push to main triggers deployment | | Reduced Human Error | No manual uploads required | | Fast Global Delivery | CloudFront serves content from edge locations | | Cost Effective | S3 + CloudFront is inexpensive for static sites | | Version Controlled | Infrastructure workflow lives alongside application code | Prerequisites Before setting up the workflow, I configured: A Next.js application using static export An Amazon S3 bucket for hosting static assets A CloudFront distribution in front of the bucket An IAM user with deployment permissions GitHub repository secrets Required GitHub Secrets | Secret | Purpose | |----------|---------| | AWS_ACCESS_KEY_ID | AWS access key | | AWS_SECRET_ACCESS_KEY | AWS secret key | | AWS_REGION | Deployment region | | S3_BUCKET_NAME | Target S3 bucket | | CLOUDFRONT_DISTRIBUTION_ID | CloudFront distribution | The GitHub Actions Workflow Conclusion With GitHub Actions handling the build, Amazon S3 hosting the static assets, and CloudFront serving content globally, every push to the main branch automatically deploys the latest version of the website. This setup provides a simple, reliable, and repeatable deployment pipeline for static Next.js applications.
June 5, 2026
Why Modern AI Applications Need an LLM Gateway Introduction When building AI applications, many teams start by calling a model provider directly from their application. This works well in the beginning, but as applications grow, several challenges emerge: Multiple model providers Cost tracking Rate limits Observability Failover requirements Governance and security This is where an LLM Gateway becomes valuable. What is an LLM Gateway? An LLM Gateway acts as a centralized layer between your application and model providers. Instead of: You introduce a gateway: The gateway becomes the control plane for all AI traffic. High-Level Architecture Problems an LLM Gateway Solves | Problem | Solution | |----------|----------| | Vendor lock-in | Route across providers | | Downtime | Automatic failover | | Cost management | Intelligent model routing | | Visibility | Centralized logging and analytics | | Security | Centralized API key management | | Governance | Usage policies and controls | Core Features of an LLM Gateway Unified API A gateway provides a single interface regardless of the underlying model provider. Applications integrate once while the gateway handles provider-specific differences. Intelligent Routing Requests can be routed based on: Cost Latency Model capabilities User tier Workload type For example, simple tasks may use a smaller model while complex reasoning tasks are routed to more capable models. Automatic Fallbacks If a provider experiences an outage or rate limiting, the gateway can automatically switch providers. This improves reliability without requiring application changes. Observability A gateway can track: Request volume Latency Token usage Cost per request Error rates User activity These insights are often difficult to obtain when integrating providers directly. Caching Many prompts are repeated. By caching responses, organizations can: Reduce latency Lower inference costs Improve user experience Popular LLM Gateways | Gateway | Type | |----------|---------| | LiteLLM | Open Source | | Portkey | Managed Platform | | OpenRouter | Hosted Routing Layer | | Kong AI Gateway | Enterprise | | Azure AI Gateway | Enterprise | Example Production Architecture In this setup, applications interact only with the gateway while the gateway manages providers, caching, monitoring, and routing. When Do You Need an LLM Gateway? You should consider introducing a gateway when: You use multiple model providers AI spend becomes significant Reliability is important You need detailed observability You serve production traffic Governance and compliance requirements increase For small prototypes, direct integration may be sufficient. As systems scale, a gateway often becomes a foundational component. Conclusion An LLM Gateway is rapidly becoming for AI applications what API Gateways became for microservices: a centralized control plane for routing, monitoring, securing, and optimizing requests. As organizations adopt multiple models and providers, gateways help reduce complexity while improving reliability, visibility, and cost efficiency.