DEV Community: nareshipme

Fixing "No Credentials Found" when using AWS SSO Profiles in Zsh

nareshipme — Mon, 27 Apr 2026 05:50:42 +0000

TL;DR: An AWS SSO login was successful, but subsequent AWS commands failed with "No credentials found" because the shell alias was pointing to a profile name that didn't match the configured credential block in ~/.aws/config.

I wanted to automate my AWS authentication by creating an alias in my .zshrc to trigger the SSO login process. After running the command, the terminal reported Login successful, but any subsequent attempt to list S3 buckets or use the AWS CLI resulted in a credential error.

The issue stemmed from a mismatch between how the profile was defined in ~/.aws/config and how I was calling it via the CLI.

Here is the configuration block I had in my ~/.aws/config:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

When I ran my login command, the output was:

Login successful

However, running a basic AWS command immediately after produced this error:

Unable to locate credentials. You can configure credentials manually via the 'aws configure' command.

The failure happened because even though the SSO session was active in the background, the AWS CLI does not automatically know which profile to use for subsequent commands unless explicitly instructed. If my alias or environment variable was pointing to a generic default profile, the CLI looked for credentials under [default], found nothing, and failed—ignoring the fact that a valid SSO session existed for the specific 123456789012_AWSEngineerAccessRole profile.

To fix this, I updated my .zshrc alias to ensure every command explicitly references the correct profile name defined in the config file:

# Before (failed because it defaulted to 'default' profile)
alias awslogin="aws sso login"

# After (explicitly targets the SSO profile)
alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"
alias aws='aws --profile 123456789012_AWSEngineerAccessRole'

By appending --profile 123456789012_AWSEngineerAccessRole to the login command, the CLI maps the successful authentication token specifically to that profile block. By aliasing aws itself, I ensure all subsequent commands bypass the empty [default] profile and use the authenticated SSO session.

Why We Switched to Streaming Frame Extraction for Mobile Video Editing

nareshipme — Fri, 24 Apr 2026 15:32:19 +0000

When we first started building ClipCrafter's browser-based video engine, our biggest enemy wasn’t the complexity of FFmpeg—it was something much more silent and deadly: Memory Exhaustion.

If you are working with high-resolution clips or long durations in a Web Worker, there is an invisible wall you will eventually hit. We call it "The OOM (Out Of Render) Wall."

Recently, we noticed that while our desktop users were enjoying smooth multi-clip stitching, mobile Chrome and Safari users on mid-range Androids/iPhones were experiencing frequent tab crashes during the rendering process. The culprit? Our frame extraction logic was attempting to hold too much in memory at once.

The Problem: $O(n)$ Memory Complexity

In our early architecture of framewebworker, we used a pattern that looked like this conceptually (simplified for clarity):

// ❌ THE OLD WAY: High risk of OOM crashes on mobile
async function extractFramesAllAtOnce(videoSource: Blob) {
  const frames = []; // This array grows linearly with video length!
  let currentTime = 0;

  while (currentTime < duration) {
    // We were grabbing a frame, converting it to an ImageBitmap/Blob...
    const frame = await captureFrameAt(videoSource, currentTime);
    frames.push(frame); // Every single frame stays in RAM until the end
    currentTime += interval; 
  }

  return frames; // If you have 500 frames of a long clip? Goodbye memory!
}

In this "Load-All" approach, our memory complexity was $O(n)$, where $n$ is total number of extracted frames. For an 8MB video file might be fine—but for high-bitrate clips or longer sequences involving multiple stitches, the browser's heap would balloon until it hit its limit and killed the worker thread (and usually our entire app tab).

The Solution: Streaming Extraction

To fix this, we upgraded framewebworker to version 0.4.0 with a focus on Streaming Frame Extraction. Instead of accumulating an array of frames in memory before starting the stitch process, we moved toward $O(1)$ spatial complexity relative to total frame count (per step).

We refactored our pipeline so that each extracted frame is processed through its next stage immediately—whether it's being passed into a WebCodecs encoder or written as part of an intermediate stream.

Here’s how we restructured the logic:

// ✅ THE NEW WAY: Streaming approach (O(1) memory footprint per step)
async function processFramesStreaming(videoSource: Blob, onFrameReady: Callback<Blob>) {
  let currentTime = 0;
  const interval = 1 / 30; // target fps

  while (currentTime < duration) {
    // Extract ONLY the current frame needed for this specific timestamp
    const singleFrameBuffer = await captureSingleFrame(videoSource, currentTime);

    /**
     * Instead of pushing to a massive global array 'frames', 
     * we emit it immediately. The downstream consumer (WebCodecs) 
     * processes the frame and then allows this buffer to be garbage collected.
     */
    await onFrameReady(singleFrameBuffer);

    currentTime += interval;
  }
}

Why This Matters for Developers Building Heavy Web Apps

By moving from an "Accumulate-then-Process" model to a Streaming model, we achieved two critical wins:

Memory Stability: The memory footprint of our worker is now tied more closely to the size of one single frame rather than total video duration/frame count. This makes mobile rendering significantly more reliable even on low-end devices with restricted heap sizes.
Time To First Byte (TTFB) for Rendering: Because we start processing frames as soon as they are extracted, our downstream encoders can begin working immediately without waiting for the "extraction phase" to finish entirely.

The Takeaway

When building resource-intensive features in JavaScript—whether it’s video editing with FFmpeg/WebCodecs or heavy data visualization—always ask yourself: Is my memory usage $O(n)$?

If your app's stability degrades as the input size increases, you don't have a logic bug; you have an architectural bottleneck. Switching to streaming-based processing is often more difficult than simple array manipulation (due to managing backpressure and state), but it’s what makes "pro" web tools possible on mobile browsers.

ClipCrafter continues to evolve! Check out our latest updates for even faster WebCodecs hardware acceleration.

Fixing "No Credentials Found" when using AWS SSO Profiles in Zsh

nareshipme — Fri, 24 Apr 2026 06:31:24 +0000

TL;DR: An AWS CLI alias was failing with "No credentials found" because the shell command was not explicitly pointing to the specific named profile configured for SSO. I fixed this by appending --profile to the command execution within the Zsh alias.

I set up a new Zsh alias to automate my AWS SSO login process and update my local ~/.aws/credentials file. The configuration in my ~/ .aws/config looked correct:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

However, when running my custom login alias, the CLI returned this error:

error: No credentials found in the configured profile.

The issue was that aws sso login does not automatically assume you want to use a specific named profile if it isn't the [default] profile. If your configuration uses a custom profile name like 123456789012_AWSEngineerAccessRole, running a bare aws sso login command causes the CLI to look for credentials under the [default] block. Since that block was empty or missing the SSO metadata, it failed immediately.

To fix this, I updated my .zshrc alias to explicitly reference the profile name using the --profile flag:

# Before (Failing)
alias awslogin="aws sso login"

# After (Working)
alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"

By adding --profile, the AWS CLI knows exactly which block in ~/.aws/config to parse for the sso_start_url and sso_account_id. Now, running awslogin triggers the browser authentication flow and correctly maps the session tokens to that specific profile.

The domain name was just productive procrastination

nareshipme — Thu, 23 Apr 2026 15:54:37 +0000

I finally reached a point with ClipCrafter where I had nothing left to hide behind in the code.

The features were all there—authentication flows working perfectly, transcription logic solid, clip generation functional, and even an export system that didn't crash every five minutes. After about 238 pull requests, it wasn’t just a "cool experiment" anymore; it was actually running like a real product. But despite having the tech ready to go, I kept delaying one specific thing: getting a domain name.

There is something deeply uncomfortable about attaching your own URL to an unfinished idea. As long as everything lived on some random deployment sub-domain or localhost, any bugs were just "developer quirks." Once you buy something.com, the project becomes real. It’s no longer yours alone; it belongs to whoever finds that link in a Google search and decides whether they like what they see.

When I finally forced myself to face this hurdle last week, I hit an immediate wall of frustration.

clipcrafter.com? Taken.
clipcrafter.app? Taken.
clipcrafter.io? Taken.
clipcrafter.video? Also taken.

I even had a brief moment where I considered just using my personal brand domain, kshan.ai. It felt safe because it was already mine and nothing could change with me personally failing at this project—but that would have been dishonest to the product itself. ClipCrafter needed its own identity.

Instead of spiraling into a naming crisis, I decided to stop manual searching and wrote a quick script to check availability for different prefixes across various TLDs programmatically. It was much less emotional than clicking through domain registrars one by one. That’s when I found getclipcrafter.com.

It wasn't "perfect," but it followed the classic indie hacker playbook—the same pattern used by giants like Postman (getpostman.com) or Figma (before they moved to their primary). It was cheap, available, and descriptive enough that people would know exactly what I do. Within minutes of buying it, my DNS records were updated and pointed at a live production deployment.

Looking back on the last few days spent obsessing over TLDs ($com vs $io) or prefix choices (get- vs try-) was actually quite revealing to me. The domain research wasn't about branding; it was productive procrastination. I used "finding the perfect name" as a shield against launching because once that URL is live, you can no longer hide from feedback.

The fear of someone using the tool and finding it broken or useless became much more concrete the moment getclipcrafter.com appeared in my browser bar. But strangely enough, making that fear real made it easier to face. You can't fix a product if nobody is looking at you actually ship it.

The app is officially live now. No more excuses—time to find those first users and see what they think of the mess I’ve built.

When Turbopack Breaks Your Web Worker Builds

nareshipme — Thu, 23 Apr 2026 15:32:10 +0000

In the world of modern frontend development, "speed" is usually a good thing. We want faster hot reloads during development and lightning-fast build times for production.

Recently at ClipCrafter, we hit this wall head-on when upgrading to Next.js 16. While moving towards Turbopack promised us incredible developer experience improvements, it introduced a silent killer: our video processing engine stopped working in production builds because of how Webpack handles worker files differently than Turbo/Turbopack does during the build pipeline.

The Problem: A Broken Worker Pipeline

ClipCrafter relies heavily on @ffmpeg/ffmpeg to handle heavy-duty video manipulation directly in the browser. This requires loading a specific .wasm file and an ESM worker via a Blob URL at runtime.

To make this work, we had configured a custom Webpack loader in next.config.ts. We needed specifically told webpack how to treat these files so they wouldn't be mangled during the bundling process:

// next.config.ts (The "Old" Way that worked)
const nextConfig = {
  webpack: (config, { isServer }) => {
    if (!isServer) {
      // We needed this custom loader to ensure ffmpeg-core 
      // could be resolved correctly via Blob URLs at runtime.
      config.module.rules.push({
        test: /ffmpeg\/dist\/esm\/worker\.js$/,
        loader: 'url-loader', // Or specialized worker loaders
      });
    }
    return config;
  },
};

When we upgraded, Next.js started defaulting to Turbopack for builds in certain environments. Since our configuration was strictly targeting the webpack object and didn't provide a corresponding Turbo-compatible instruction set via turbo: { rules: ... }, those critical worker files were being bundled incorrectly. The result? A production build that looked perfect but crashed with an "Uncaught TypeError" as soon as you tried to initialize any video clip processing.

Moving Toward Hardware Acceleration

While fixing the bundler, we also had a chance to look at our performance bottleneck. We realized ffmpeg.wasm was great for compatibility, but it's essentially running software-based encoding in JavaScript—which is slow and heavy on CPU usage.

We decided to upgrade/integrate with @framewebworker@0.3.0. This library uses WebCodecs, a modern browser API that allows us to tap into the device’s hardware acceleration (H.264). The difference was night and day: we saw encoding speeds jump from "painfully slow" up to 10–50× faster on supported browsers, with an automatic fallback to our existing FFmpeg setup for older devices.

How We Fixed It

To get the build pipeline stable again while embracing these upgrades, we had two main tasks in a single PR:

Force Webpack for Production: Until Next.js provides more robust Turbopack configuration hooks specifically for complex WASM/Worker loaders like ours, we explicitly forced webpack during our production builds to ensure the @ffmpeg/ffmpeg worker remains intact and resolvable at runtime.
Clean up Route Exports: We also had a minor type-safety issue where arbitrary constants (like language lists) were being exported from Next.js App Router files, causing TypeScript violations in generated types during build time. In route.ts, you should only export HTTP handlers (GET, POST) and config objects.

The Lesson Learned

If your application relies on "heavy" browser APIs like WebAssembly (WASM), SharedArrayBuffer, or complex Worker threads: Don't assume the new default bundler just works.

The transition from Webpack to Turbopack is a massive leap forward for dev speed, but it requires you to audit how your most critical pieces of infrastructure—the ones that don't follow standard "UI component" rules—are being bundled. We fixed our build by reverting the production engine back to its proven Webpack configuration while keeping all other Next.js 16 benefits intact.

Have you run into bundling issues with newer versions of Next.js? Let us know in the comments!

Debugging "No Credentials Found" when Aliasing AWS SSO Login in ZSH

nareshipme — Thu, 23 Apr 2026 12:13:53 +0000

TL;DR: Creating a ZSH alias that runs aws sso login appeared to succeed, but subsequent commands failed with "no credentials found" because the alias was not correctly setting the profile for downstream tools.

I was trying to streamline my workflow by adding an alias to my .zshrc to automate logging into a specific AWS SSO profile. The goal was simple: run one command, and have all subsequent AWS CLI commands work immediately using that authenticated session.

The alias looked like this in my .zshrc:

alias awslogin="aws sso login --profile 123456789012_AWSEngineerAccessRole"

When I ran awslogin, the terminal returned:

Login successful

However, as soon as I tried to list my S3 buckets using that same profile, the CLI threw a credential error:

fatal error: An error occurred (NoCredentialsError) when calling the ListBuckets operation: unable to locate credentials.

The Root Cause

The issue was not with the SSO login itself — the browser-based authentication was completing successfully and updating the token cache in ~/.aws/sso/cache. The problem was a mismatch between how I was initiating the session and how my AWS configuration was structured.

In my ~/.aws/config, I had defined the profile like this:

[profile 123456789012_AWSEngineerAccessRole]
sso_start_url = https://your-org.awsapps.com/start
sso_region = eu-west-2
sso_account_id = 123456789012
sso_role_name = AWSEngineerAccessRole
region = eu-west-2

While aws sso login --profile <name> successfully refreshed the SSO token, subsequent commands were failing because they were not explicitly told to use that specific profile. The AWS CLI defaults to looking for a [default] profile or AWS_ACCESS_KEY_ID environment variables. Since neither was set, it found nothing — even though the SSO token was valid.

The Fix

Update the alias to also export AWS_PROFILE after a successful login:

alias awslogin='aws sso login --profile 123456789012_AWSEngineerAccessRole && export AWS_PROFILE=123456789012_AWSEngineerAccessRole'

The && means the export only runs if the login succeeded. From that point, every subsequent command in the shell session picks up the correct profile automatically — no --profile flag needed.

Verification:

$ awslogin
Login successful
$ aws s3 ls
[your buckets appear]
$ aws sts get-caller-identity
{
    "UserId": "...",
    "Account": "123456789012",
    "Arn": "arn:aws:sts::123456789012:assumed-role/AWSEngineerAccessRole/..."
}

The sts get-caller-identity check is worth adding to your alias or running manually after login — it confirms the session is actually active, not just that the token handshake completed.

Why We Switched from Stripe to Razorpay for ClipCrafter’s Billing Engine

nareshipme — Wed, 22 Apr 2026 14:01:20 +0000

Building a SaaS is rarely just about the core feature. For us at ClipCrafter—an AI-powered video editor—the "video" part was actually one of our easier challenges. The real complexity crept in when we had to figure out how to charge people for it.

Recently, we hit a major milestone: moving from an experimental Stripe setup into a production-ready billing system powered by Razorpay. While many developers default to Stripe because of its incredible documentation and global footprint, scaling ClipCrafter required us to rethink our payment architecture based on specific regional needs and usage enforcement.

The "Why" Behind the Pivot

When we first started prototyping Phase 10 (our Billing & Payments phase), a dual-provider approach seemed attractive for international coverage via Stripe + Razorpay. However, as development progressed, it became clear that maintaining two separate webhooks, two different subscription lifec/ycles, and twofold error handling was creating massive technical debt in our Inngest workflows.

We decided to simplify: Razorpay only.

By focusing on a single provider for the initial launch phase (specifically targeting India-based payments), we were able to prune significant amounts of boilerplate code from both our Next.js API routes and our background workers. We removed stripe_subscription_id entirely, cleaned up our database migrations in Supabase, and focused strictly on usage enforcement via a unified schema.

Implementing Usage Enforcement

The real challenge wasn't just "taking money"—it was ensuring that if someone is on the 'Starter' plan, they don’t accidentally trigger an unlimited number of high-compute video renders using our WebWorker architecture.

We needed a way to check usage limits before every single rendering job hit our worker queue via Inngest. Here is how we structured that logic in TypeScript:

// src/lib/billing.ts - Simplified Usage Check Logic

import { createClient } from '@supabase/supabase-js';

interface UserBillingRow {
  planKey: 'starter' | 'pro';
  videoCreditsRemaining: number;
}

export async function validateRenderPermissions(userId: string, supabaseClient: any) {
  // 1. Fetch the current user billing status from Supabase
  const { data: billingData, error } = await supabaseClient
    .from('user_billing')
    .select('planKey, videoCreditsRemaining')
    .eq('id', userId)
    .single();

  if (error || !billingData) {
    throw new Error("Could not retrieve billing information.");
  }

  const { planKey, videoCreditsRemaining } = billingData as UserBillingRow;

  // 2. Enforce hard limits based on the Plan Key
  console.log(`Checking permissions for ${planKey} user...`);

  if (videoCreditsRemaining <= 0) {
    throw new Error("No credits remaining! Please upgrade your plan.");
  }

  return true; // Permission granted to proceed with rendering task
}

The Lesson: Pruning is as important as Adding

The most satisfying part of this refactor wasn't adding the Razorpay integration—it was deleting everything related to Stripe. We removed entire client libraries, deleted webhook listeners that were no longer being triggered, and cleaned up our PlanBadge components which previously had "zombie" styles for plans we weren't even supporting anymore via a specific provider.

In software engineering (and especially in early-stage startups), there is an immense temptation to build every possible integration from Day 1 just because you might need it later. We learned that the complexity of managing two payment gateways far outweighed any potential benefit for our current user base.

Takeaway

If you're building a global SaaS, don't let "feature creep" infect your core infrastructure before they even pay their first invoice. Pick one provider, master its webhook lifecycle and usage enforcement patterns (like we did with Inngest + Supabase), and only expand when the market—not your imagination—demands it.

What’s your experience with payment gateways? Did you stick to Stripe or find a more localized solution for much of less friction? Let us know in the comments!

Dev Journal: 2026-04-21

nareshipme — Tue, 21 Apr 2026 06:42:21 +0000

/Users/ONBAdmin/Development/term-sheet/scripts/daily-blog.sh: line 132: /users/ONBAdmin/.nvm/versions/node/v20.19.0/bin/claude: No such file or directory

Dev Journal: 2026-04-21

nareshipme — Tue, 21 Apr 2026 06:30:08 +0000

Not logged in · Please run /login

Dev Journal: 2026-04-20

nareshipme — Mon, 20 Apr 2026 05:30:09 +0000

Not logged in · Please run /login

Dev Journal: 2026-04-17

nareshipme — Thu, 16 Apr 2026 18:30:02 +0000

env: node: No such file or directory

Dev Journal: 2026-04-16

nareshipme — Wed, 15 Apr 2026 18:32:11 +0000

env: node: No such file or directory