DEV Community: Ishan Jarwal

Asynchronous Jobs made easy with Inngest | Learn how to setup Inngest in a Typescript Project

Ishan Jarwal — Tue, 22 Sep 2026 18:01:50 +0000

Inngest with Next.js and TypeScript: A Practical Guide to Background Jobs, Workflows, Retries, and Debugging

If you've ever written a Next.js API route that starts doing too much, you've probably run into this problem:

"The user doesn't actually need to wait for this."

Maybe you're sending an email after signup.

Maybe you're generating a PDF.

Maybe you're processing uploaded images.

Maybe you're syncing data with Stripe, Shopify, a CRM, or some third-party API.

Or maybe you've got a workflow that looks something like:

User signs up
   ↓
Create account
   ↓
Send welcome email
   ↓
Create CRM contact
   ↓
Wait 2 days
   ↓
Send follow-up email

You can put all of this inside a regular Next.js request.

But eventually you'll start worrying about timeouts, retries, failed API calls, duplicated work, cron jobs, queues, workers, and what happens if your server dies halfway through the process.

That's where Inngest becomes useful.

Inngest gives you an event-driven way of running background jobs and durable workflows without having to build and maintain your own queue infrastructure. It provides things like retries, steps, delayed execution, concurrency controls, observability, and execution history.

This guide walks through setting it up from scratch in a TypeScript Next.js application and, more importantly, explains what each file is doing and why it exists.

What we're going to build

By the end, we'll have a Next.js application that looks roughly like this:

Next.js application
       │
       │ sends event
       ▼
   Inngest
       │
       │ triggers
       ▼
 Inngest Function
       │
       ├── Step 1
       ├── Step 2
       ├── Step 3
       └── Step 4

We'll build a small example around a user signup.

When a user signs up, we'll send an event:

app/user.created

Inngest will receive that event and trigger a function.

That function will:

Fetch the user.
Send a welcome email.
Update some external system.
Wait for a short period.
Send a follow-up.

The individual pieces will be represented as Inngest steps, which gives us retryability and durable execution.

1. First, what problem is Inngest actually solving?

Before installing anything, it's worth understanding the mental model.

Suppose you have this API route:

export async function POST(request: Request) {
  const user = await createUser();

  await sendWelcomeEmail(user);

  await syncWithCRM(user);

  return Response.json({
    success: true,
  });
}

It works.

But your HTTP request now depends on three things:

createUser
    ↓
sendWelcomeEmail
    ↓
syncWithCRM

If syncWithCRM() takes 10 seconds, the request takes 10 seconds.

If the CRM is temporarily unavailable, the whole request can fail.

If the email succeeds but the CRM fails, you have to decide what happens when the client retries the original request.

That's where background execution starts becoming valuable.

With Inngest, your request can instead do this:

await inngest.send({
  name: "app/user.created",
  data: {
    userId: user.id,
  },
});

The HTTP request can finish.

Inngest then takes over:

HTTP request
    │
    └── publish event
             │
             ▼
        Inngest
             │
             ▼
      user-created function
             │
             ├── fetch user
             ├── send email
             ├── sync CRM
             └── follow-up

That's the basic idea.

2. When should you use Inngest?

A useful rule of thumb is:

If the user doesn't need to wait for the operation, it's a good candidate for Inngest.

Common examples include:

Sending emails
Processing uploaded files
Generating reports
Image/video processing
Webhook processing
Stripe-related background work
CRM synchronization
Notifications
Scheduled jobs
Data synchronization
AI workflows
Long-running processes
Multi-step workflows
Retryable API calls

Inngest functions can be triggered by events, schedules, and other workflow mechanisms. Steps can also pause, wait for events, invoke other functions, and retry independently.

3. Prerequisites

For this guide, I'm assuming:

Node.js is installed
You have a TypeScript Next.js project
You're using the Next.js App Router
Your project uses npm

For example:

Next.js
TypeScript
App Router
src/ directory

If you're starting from scratch:

npx create-next-app@latest inngest-nextjs

Then:

cd inngest-nextjs

And start your application:

npm run dev

4. Install Inngest

Inside your project:

npm install inngest

That's all you need for the SDK.

The current Inngest Next.js quick start also uses:

npm install inngest

for the TypeScript SDK.

5. The folder structure

Now let's organize the project.

There are many ways to structure Inngest code. You don't have to follow this exact structure, but this is a clean starting point:

src/
├── app/
│   ├── api/
│   │   └── inngest/
│   │       └── route.ts
│   │
│   └── page.tsx
│
├── inngest/
│   ├── client.ts
│   ├── functions/
│   │   ├── user-created.ts
│   │   └── index.ts
│   └── index.ts
│
└── lib/
    ├── email.ts
    ├── db.ts
    └── crm.ts

You don't necessarily need all these files on day one.

The important pieces are:

inngest/client.ts
inngest/functions/*
app/api/inngest/route.ts

Let's look at what each one does.

6. `src/inngest/client.ts`

This file creates your Inngest client.

Create:

src/inngest/client.ts

Then:

import { Inngest } from "inngest";

export const inngest = new Inngest({
  id: "my-nextjs-app",
});

That's it.

This client becomes the central object used to:

create Inngest functions
send events
configure your application identity
communicate with Inngest

Think of this file as:

"This is my application talking to Inngest."

The id should represent your application.

For example:

export const inngest = new Inngest({
  id: "acme-web",
});

Keep the ID stable. Function IDs should also remain stable between deployments because Inngest uses them to identify functions.

7. Create your first Inngest function

Now let's make the interesting part.

Create:

src/inngest/functions/user-created.ts

We'll start with something simple.

import { inngest } from "../client";

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
  },
  {
    event: "app/user.created",
  },
  async ({ event }) => {
    console.log("New user:", event.data.userId);

    return {
      success: true,
    };
  }
);

The important pieces are:

inngest.createFunction(...)

This creates the function.

Then:

id: "user-created"

gives the function a stable identifier.

And:

event: "app/user.created"

says:

"Run this function whenever an app/user.created event happens."

Inngest's current SDK documentation uses the v4 function configuration style with triggers, so the equivalent current form is:

import { inngest } from "../client";

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
    triggers: {
      event: "app/user.created",
    },
  },
  async ({ event }) => {
    console.log(event.data.userId);
  }
);

Use the v4 form in new projects.

8. Export your functions

Create:

src/inngest/functions/index.ts

Then:

export { userCreated } from "./user-created";

This may seem unnecessary when you only have one function.

But imagine your application eventually has:

functions/
├── user-created.ts
├── send-welcome-email.ts
├── process-payment.ts
├── generate-report.ts
├── sync-crm.ts
└── cleanup-expired-data.ts

Having one central export makes the route much cleaner.

9. Create the Inngest API route

This is the part that often confuses people.

Your Next.js application needs an HTTP endpoint that Inngest can communicate with.

Create:

src/app/api/inngest/route.ts

Then:

import { serve } from "inngest/next";

import { inngest } from "@/inngest/client";
import { userCreated } from "@/inngest/functions";

export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [userCreated],
});

If you have multiple functions:

import { serve } from "inngest/next";

import { inngest } from "@/inngest/client";
import {
  userCreated,
  sendWelcomeEmail,
  processPayment,
} from "@/inngest/functions";

export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [
    userCreated,
    sendWelcomeEmail,
    processPayment,
  ],
});

This route is normally available at:

/api/inngest

The serve() handler allows Inngest to discover your functions and invoke them through your application.

So conceptually:

Inngest
   │
   │ HTTP
   ▼
/api/inngest
   │
   ▼
Next.js
   │
   ├── userCreated
   ├── sendWelcomeEmail
   └── processPayment

This endpoint is one of the most important pieces of the setup.

10. Your project should now look something like this

src/
├── app/
│   └── api/
│       └── inngest/
│           └── route.ts
│
└── inngest/
    ├── client.ts
    │
    └── functions/
        ├── index.ts
        └── user-created.ts

And each file has a very specific responsibility:

File	Responsibility
`inngest/client.ts`	Creates the Inngest client
`inngest/functions/*.ts`	Contains your actual background functions
`inngest/functions/index.ts`	Exports all functions
`app/api/inngest/route.ts`	Exposes the functions to Inngest

That's really the core architecture.

11. Run the Inngest Dev Server

This is where Inngest gets really nice during development.

You don't need to immediately create a cloud project just to test your function.

Inngest provides a local Dev Server that lets you:

discover your functions
send events
inspect runs
inspect errors
view step execution
rerun functions
cancel runs
debug workflows

The current Dev Server runs on port 8288 by default.

You can start it with:

npx inngest-cli@latest dev

Or install the CLI and run:

inngest dev

Then open:

http://localhost:8288

You should see the Inngest development UI.

12. Run Next.js in development mode

In another terminal:

npm run dev

For the current SDK, you can explicitly tell Inngest that you're working locally:

INNGEST_DEV=1

Put that in:

.env.local

So your .env.local might contain:

INNGEST_DEV=1

In Dev Mode, the SDK communicates with your local Inngest Dev Server rather than Inngest Cloud. Signing keys aren't required for the local Dev Server.

13. Trigger your first event

Now we need to actually send:

app/user.created

There are several ways to do this.

The simplest is from your server-side application code.

For example:

import { inngest } from "@/inngest/client";

await inngest.send({
  name: "app/user.created",
  data: {
    userId: "user_123",
  },
});

That's the event.

Notice the event structure:

{
  name: "app/user.created",
  data: {
    userId: "user_123"
  }
}

The name is what determines which functions are triggered.

The data is the payload your function receives.

Inside your function:

async ({ event }) => {
  console.log(event.data.userId);
}

you'll get:

user_123

Event keys are required for sending events to Inngest Cloud in production, but they're not required when using the local Dev Server.

14. A more realistic example

Let's make this useful.

Suppose a user registers.

Our application creates the user:

const user = await db.user.create({
  data: {
    email,
    name,
  },
});

Then we don't want to make the HTTP request wait for everything else.

So:

await inngest.send({
  name: "app/user.created",
  data: {
    userId: user.id,
  },
});

Now our Inngest function can handle the rest.

import { inngest } from "../client";

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
  },
  {
    event: "app/user.created",
  },
  async ({ event, step }) => {
    const user = await step.run("get-user", async () => {
      // Fetch the user from your database
      return getUser(event.data.userId);
    });

    await step.run("send-welcome-email", async () => {
      await sendWelcomeEmail(user);
    });

    await step.run("sync-crm", async () => {
      await syncUserWithCRM(user);
    });

    return {
      userId: user.id,
    };
  }
);

The current v4 syntax is:

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
    triggers: {
      event: "app/user.created",
    },
  },
  async ({ event, step }) => {
    // ...
  }
);

Again, use this v4 form for a new project.

15. Why `step.run()` matters

This is probably the most important Inngest concept to understand.

You might initially write:

await sendWelcomeEmail(user);

await syncCRM(user);

But with Inngest, you'd normally structure meaningful side effects as steps:

await step.run("send-welcome-email", async () => {
  await sendWelcomeEmail(user);
});

await step.run("sync-crm", async () => {
  await syncCRM(user);
});

Why?

Because steps are independently tracked and retried.

If this happens:

get-user        ✓
send-email      ✓
sync-crm        ✗

Inngest doesn't need to blindly start the whole function from scratch.

The completed work is checkpointed, and the failed step can be retried.

This is one of the core ideas behind Inngest's durable execution model.

16. Don't put important side effects outside steps

This is a very important practical rule.

Avoid:

await sendEmail();

await step.run("save-user", async () => {
  await db.user.update(...);
});

If your function is replayed, the email operation isn't represented as an Inngest step.

Prefer:

await step.run("send-email", async () => {
  await sendEmail();
});

await step.run("save-user", async () => {
  await db.user.update(...);
});

Database writes, API calls, emails, payment operations, and similar side effects are usually good candidates for step.run().

Inngest specifically recommends putting nondeterministic side effects such as database writes and API calls inside steps so completed work can be checkpointed.

17. Retries

One of the nicest things about steps is retry behavior.

Imagine:

await step.run("send-email", async () => {
  await emailProvider.send(...);
});

If your email provider temporarily returns an error, the step can be retried according to your function's retry configuration.

Each step has its own retry counter.

That's much more useful than writing this everywhere:

try {
  await something();
} catch {
  await something();
}

You don't want retry logic scattered throughout your application.

Let your workflow layer handle it.

18. Sleeping without keeping a server request open

This is another area where Inngest becomes particularly useful.

Imagine:

User signs up
      ↓
Send welcome email
      ↓
Wait 3 days
      ↓
Send onboarding email

You don't want to keep a Node.js process sitting around for three days.

With Inngest:

await step.sleep("wait-before-follow-up", "3 days");

Then:

await step.run("send-follow-up", async () => {
  await sendFollowUpEmail();
});

The function can pause and resume later rather than keeping a normal HTTP request alive.

The SDK provides step APIs including sleep, sleepUntil, waitForEvent, invoke, and sendEvent.

19. A complete workflow example

Here's what a slightly more realistic onboarding workflow could look like:

import { inngest } from "../client";

export const onboardingWorkflow = inngest.createFunction(
  {
    id: "user-onboarding",
  },
  {
    event: "app/user.created",
  },
  async ({ event, step }) => {
    const user = await step.run("get-user", async () => {
      return getUser(event.data.userId);
    });

    await step.run("send-welcome-email", async () => {
      await sendWelcomeEmail(user);
    });

    await step.run("create-crm-contact", async () => {
      await createCRMContact(user);
    });

    await step.sleep(
      "wait-before-onboarding-email",
      "3 days"
    );

    await step.run("send-onboarding-email", async () => {
      await sendOnboardingEmail(user);
    });

    return {
      success: true,
      userId: user.id,
    };
  }
);

Now your workflow is readable almost like a checklist:

Get user
   ↓
Send welcome email
   ↓
Create CRM contact
   ↓
Wait 3 days
   ↓
Send onboarding email

And that's really one of the strengths of Inngest.

The code describes the workflow instead of forcing you to build your own queue/state machine infrastructure.

20. Environment variables

There are a few Inngest environment variables worth knowing.

For local development:

INNGEST_DEV=1

For production:

INNGEST_EVENT_KEY=...
INNGEST_SIGNING_KEY=...

Potentially:

INNGEST_SIGNING_KEY_FALLBACK=...

during signing-key rotation.

There are also configuration variables such as:

INNGEST_BASE_URL=...
INNGEST_ENV=...
INNGEST_LOG_LEVEL=...
INNGEST_SERVE_ORIGIN=...
INNGEST_SERVE_PATH=...
INNGEST_STREAMING=...

Not every application needs all of these.

A typical production setup might look like:

INNGEST_EVENT_KEY=your-event-key
INNGEST_SIGNING_KEY=your-signing-key

Keep these secrets out of Git.

Don't do this:

const inngest = new Inngest({
  id: "my-app",
  signingKey: "super-secret-key",
});

Prefer environment variables.

Inngest explicitly recommends using INNGEST_SIGNING_KEY instead of hard-coding the signing key.

21. Event Key vs Signing Key

These two are easy to mix up.

Event Key

An Event Key is used by your application to send events to Inngest.

For example:

await inngest.send({
  name: "app/user.created",
  data: {
    userId: "123",
  },
});

In production, the SDK can use:

INNGEST_EVENT_KEY=...

Event keys are environment-specific.

Signing Key

The Signing Key is about securely communicating between your deployed application and Inngest.

INNGEST_SIGNING_KEY=...

In other words:

EVENT KEY
   ↓
"My application can send events"

SIGNING KEY
   ↓
"Secure communication between Inngest and my app"

Don't confuse the two.

22. What happens in production?

Locally you have:

Next.js
localhost:3000

       ↕

Inngest Dev Server
localhost:8288

In production, the architecture is closer to:

Your Next.js deployment
        │
        │ /api/inngest
        │
        ▼
   Inngest Cloud
        │
        │
        ▼
  Function execution

For serverless platforms such as Vercel, the normal approach is to expose the serve() handler through your application at /api/inngest.

23. Deploying with Vercel

If you're using Next.js, Vercel is probably the deployment platform you'll encounter most often.

Your application already has:

/api/inngest

So after deploying the application, Inngest needs to be able to reach that endpoint.

For production, configure:

INNGEST_EVENT_KEY=...
INNGEST_SIGNING_KEY=...

in your production environment.

Inngest also provides a Vercel integration that can help configure the necessary integration.

The exact deployment workflow can change depending on your Vercel/Inngest setup, so when deploying a real application, it's worth checking the current Inngest deployment documentation rather than blindly copying an old blog post.

24. Inngest environments

This is something you should understand before your project becomes a team project.

Inngest supports separate environments, including:

Production
Branch environments
Custom environments
Local development

The point is isolation.

You don't want your local testing to accidentally trigger production workflows.

Each environment has isolated event/function data and its own keys.

A typical team setup might look like:

Local
  ↓
Dev Server

Feature branch
  ↓
Branch environment

Staging
  ↓
Custom environment

Production
  ↓
Production environment

If you're working alone, you can start with:

Local → Production

and introduce additional environments when you actually need them.

25. The Inngest Portal / Dashboard

Once you're working with Inngest Cloud, the dashboard becomes your control room.

You'll typically use it to inspect:

Applications
Functions
Events
Function runs
Errors
Retries
Execution traces
Environments

The important thing to remember is that the dashboard isn't just a place to see whether something succeeded.

It's where you can investigate why it succeeded or failed.

Inngest's run view provides information about the event payload, execution timeline, steps, timings, errors, and retries.

26. Debugging locally

When something doesn't work, don't immediately start adding random console.log() calls everywhere.

First open:

http://localhost:8288

and look at the run.

You should be able to see:

Function
   ↓
Run
   ↓
Step 1
   ↓
Step 2
   ↓
Step 3

If a step fails, inspect that step.

For example:

user-created

✓ get-user
✓ send-welcome-email
✗ sync-crm

Now you know exactly where the problem is.

That's much easier than looking at a giant application log.

27. Debugging production failures

Suppose you get this:

sync-crm
FAILED

Go into the Inngest dashboard and open the run.

You can inspect the execution timeline and the failed step.

The dashboard can show individual attempts and the errors associated with them. It also provides options for rerunning runs and, in some cases, replaying from a step.

That gives you a workflow like:

Production failure
      ↓
Open Inngest
      ↓
Find failed run
      ↓
Open trace
      ↓
Find failed step
      ↓
Read error
      ↓
Fix code
      ↓
Deploy
      ↓
Rerun

That's a much nicer debugging experience than manually reconstructing what happened from logs.

28. Use meaningful step IDs

This:

await step.run("step-1", async () => {
  // ...
});

works.

But this:

await step.run("create-crm-contact", async () => {
  // ...
});

is much better.

When you open the dashboard later, you immediately understand what's happening.

Good:

fetch-user
send-welcome-email
create-crm-contact
update-subscription
generate-invoice
send-invoice

Bad:

step-1
step-2
step-3
step-4

The step ID is also part of how Inngest identifies and memoizes the step, so don't casually change IDs between versions.

29. Logging

You can still use normal logging:

console.log("Processing user:", event.data.userId);

But inside an Inngest function you can also use the provided logger:

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
  },
  {
    event: "app/user.created",
  },
  async ({ event, logger }) => {
    logger.info("Processing user", {
      userId: event.data.userId,
    });
  }
);

The SDK exposes logging interfaces such as info, warn, error, and debug.

Keep logs useful.

Instead of:

console.log("here");

prefer:

logger.info("Starting CRM synchronization", {
  userId,
});

Six months later, you'll thank yourself.

30. A note about retries and duplicate side effects

Retries are great.

But retries also mean you need to think about idempotency.

For example:

await step.run("charge-customer", async () => {
  await stripe.charges.create(...);
});

You don't want a retry to accidentally charge somebody twice.

The same idea applies to:

payments
sending emails
creating external records
sending notifications
database mutations
webhook handling

Whenever an operation isn't naturally idempotent, use an idempotency key or design the operation so repeating it is safe.

For example:

await step.run("create-crm-contact", async () => {
  return crm.contacts.create({
    externalId: user.id,
    email: user.email,
  });
});

Your CRM integration might then use externalId to avoid creating duplicate contacts.

This isn't an Inngest-specific problem.

It's simply something you need to think about whenever work can be retried.

31. Don't make one giant step

You could write:

await step.run("everything", async () => {
  await sendEmail();
  await syncCRM();
  await generateReport();
  await notifySlack();
});

But now Inngest sees this as one unit of work.

If the Slack notification fails, the whole block may need to run again.

Instead:

await step.run("send-email", async () => {
  await sendEmail();
});

await step.run("sync-crm", async () => {
  await syncCRM();
});

await step.run("generate-report", async () => {
  await generateReport();
});

await step.run("notify-slack", async () => {
  await notifySlack();
});

Now you get a much clearer workflow:

send-email        ✓
sync-crm          ✓
generate-report   ✓
notify-slack      ✗

That's exactly the kind of execution history you want when debugging.

32. But don't create a step for every line either

The opposite extreme is also unnecessary.

You don't need:

await step.run("create-variable", () => {
  return "hello";
});

await step.run("uppercase-variable", () => {
  return value.toUpperCase();
});

await step.run("log-variable", () => {
  console.log(value);
});

Steps are most useful around meaningful units of work.

A good step is usually something like:

fetch data
write database
call external API
send email
generate document
charge payment

Think in terms of units that you would want to retry or inspect independently.

33. Sending multiple events

Your application can publish events whenever something interesting happens.

For example:

await inngest.send({
  name: "app/order.created",
  data: {
    orderId: order.id,
  },
});

Then a function can listen:

export const processOrder = inngest.createFunction(
  {
    id: "process-order",
  },
  {
    event: "app/order.created",
  },
  async ({ event, step }) => {
    // process order
  }
);

This gives you a useful architecture:

Business event
      │
      ▼
Inngest
      │
      ├── send confirmation email
      │
      ├── update analytics
      │
      ├── sync inventory
      │
      └── notify fulfillment

Different functions can react to the same event.

That helps keep your application loosely coupled.

34. Event naming conventions

Don't randomly name events.

Pick a convention and stick to it.

For example:

app/user.created
app/user.deleted
app/order.created
app/order.paid
app/order.cancelled
app/subscription.created
app/subscription.cancelled

A nice pattern is:

domain/entity.action

For example:

app/user.created

rather than:

newUser

It becomes much easier to understand as the number of events grows.

35. Cron jobs

Inngest isn't only for events.

Scheduled functions are another common use case.

For example, you might want to:

Every day at 2 AM
      ↓
Find expired subscriptions
      ↓
Update database
      ↓
Send notifications

The function can be configured with a cron trigger.

This is particularly useful when you have scheduled tasks that would otherwise require separate cron infrastructure.

Inngest's function model supports cron/background jobs as well as event-driven workflows.

36. Concurrency and throttling

As your application grows, you'll eventually run into another problem:

"What happens if 10,000 events arrive at once?"

You don't necessarily want 10,000 copies of the same function hammering your API or database.

Inngest supports flow-control features such as:

concurrency
throttling
rate limiting
debouncing
prioritization

For example, a function can be configured with a throttle:

{
  id: "sync-systems",
  triggers: {
    event: "app/sync.requested",
  },
  throttle: {
    limit: 3,
    period: "1m",
  },
}

The exact configuration should be chosen based on the limits of the systems you're calling.

Inngest documents these flow-control features as part of its function model.

37. Testing Inngest functions

Don't rely exclusively on the Dev Server.

You should also test your functions in your automated test suite.

Inngest provides testing utilities for executing functions and inspecting step state.

For example, its testing API can expose the state/results of individual steps, which makes it possible to test both successful and failing workflows.

This becomes particularly valuable for workflows containing business-critical logic.

A useful testing strategy is:

Unit tests
   ↓
Individual business logic

Inngest tests
   ↓
Workflow behavior

Dev Server
   ↓
Manual integration testing

Production dashboard
   ↓
Real execution monitoring

38. Keep business logic separate from Inngest

This is another architectural choice that pays off later.

Instead of putting everything directly inside:

inngest.createFunction(...)

you can keep business logic elsewhere.

For example:

src/
├── inngest/
│   └── functions/
│       └── user-created.ts
│
└── services/
    ├── users.ts
    ├── email.ts
    └── crm.ts

Then your function becomes:

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
    triggers: {
      event: "app/user.created",
    },
  },
  async ({ event, step }) => {
    const user = await step.run("get-user", () =>
      userService.getById(event.data.userId)
    );

    await step.run("send-email", () =>
      emailService.sendWelcome(user)
    );

    await step.run("sync-crm", () =>
      crmService.syncUser(user)
    );
  }
);

That's a much healthier separation.

Inngest describes when and how the work runs.

Your services describe what the work actually does.

39. A clean final folder structure

For a medium-sized project, I would aim for something like:

src/
│
├── app/
│   ├── api/
│   │   └── inngest/
│   │       └── route.ts
│   │
│   ├── dashboard/
│   └── ...
│
├── inngest/
│   ├── client.ts
│   │
│   └── functions/
│       ├── index.ts
│       ├── user-created.ts
│       ├── order-created.ts
│       ├── process-payment.ts
│       └── daily-cleanup.ts
│
├── services/
│   ├── email.ts
│   ├── crm.ts
│   ├── payments.ts
│   └── users.ts
│
├── db/
│   └── ...
│
└── lib/
    └── ...

And conceptually:

API / Server Action
        │
        │ inngest.send()
        ▼
     Event
        │
        ▼
    Function
        │
        ├── Step
        ├── Step
        ├── Step
        └── Step
             │
             ▼
          Services
             │
             ├── Database
             ├── Email
             ├── CRM
             └── APIs

40. A complete example

Let's put the pieces together.

`src/inngest/client.ts`

import { Inngest } from "inngest";

export const inngest = new Inngest({
  id: "my-nextjs-app",
});

`src/inngest/functions/user-created.ts`

import { inngest } from "../client";

export const userCreated = inngest.createFunction(
  {
    id: "user-created",
    name: "User Created",
    triggers: {
      event: "app/user.created",
    },
  },
  async ({ event, step }) => {
    const user = await step.run("get-user", async () => {
      // Replace with your real database call.
      return {
        id: event.data.userId,
        email: "user@example.com",
      };
    });

    await step.run("send-welcome-email", async () => {
      console.log(
        `Sending welcome email to ${user.email}`
      );

      // await emailService.sendWelcomeEmail(user);
    });

    await step.run("sync-crm", async () => {
      console.log(
        `Syncing ${user.id} with CRM`
      );

      // await crmService.createOrUpdateUser(user);
    });

    return {
      success: true,
      userId: user.id,
    };
  }
);

`src/inngest/functions/index.ts`

export { userCreated } from "./user-created";

`src/app/api/inngest/route.ts`

import { serve } from "inngest/next";

import { inngest } from "@/inngest/client";
import { userCreated } from "@/inngest/functions";

export const { GET, POST, PUT } = serve({
  client: inngest,
  functions: [userCreated],
});

`.env.local`

INNGEST_DEV=1

Then start two terminals.

Terminal 1:

npm run dev

Terminal 2:

npx inngest-cli@latest dev

Then open:

http://localhost:8288

Trigger:

await inngest.send({
  name: "app/user.created",
  data: {
    userId: "user_123",
  },
});

And you should see the run appear in the Dev Server.

41. The mental model I recommend

If you're new to Inngest, don't try to memorize every API.

Just remember these five things:

1. Event

Something happened.

await inngest.send({
  name: "app/order.created",
  data: {
    orderId,
  },
});

2. Function

Something should react to that event.

inngest.createFunction(...)

3. Step

This is a meaningful unit of work.

await step.run("send-email", async () => {
  // ...
});

4. Serve

This exposes your functions to Inngest.

serve({
  client: inngest,
  functions: [...],
});

5. Dev Server / Dashboard

This is where you inspect what actually happened.

localhost:8288

That's most of the foundation.

42. Common mistakes

Mistake #1: Forgetting the `/api/inngest` route

You created your function:

inngest.createFunction(...)

but forgot:

app/api/inngest/route.ts

Inngest needs a way to discover and invoke your functions.

Mistake #2: Running the wrong environment

If you're developing locally, make sure your SDK is actually in Dev Mode:

INNGEST_DEV=1

Otherwise the SDK defaults to cloud mode unless configured otherwise.

Mistake #3: Hard-coding secrets

Don't commit:

signingKey: "..."

Use:

INNGEST_SIGNING_KEY=...

instead.

Mistake #4: Putting side effects outside steps

Instead of:

await chargeCustomer();

await step.run("save-order", ...);

prefer:

await step.run("charge-customer", async () => {
  await chargeCustomer();
});

await step.run("save-order", async () => {
  await saveOrder();
});

Mistake #5: Making one enormous step

Avoid:

await step.run("do-everything", async () => {
  // 500 lines
});

Break meaningful operations into separate steps.

Mistake #6: Ignoring idempotency

If something can be retried, ask:

"What happens if this runs twice?"

Especially for:

payments
emails
database mutations
external APIs

Mistake #7: Using meaningless function IDs

Don't constantly change:

id: "user-created"

to:

id: "user-created-v2"

unless you actually intend to create a different Inngest function.

Stable IDs matter to Inngest's function identity and execution model.

43. What I'd do next in a real project

Once the basic setup works, I'd add things in roughly this order:

Step 1 — Create a proper event naming convention

For example:

app/user.created
app/user.deleted
app/order.created
app/order.paid
app/order.refunded

Step 2 — Move business logic into services

Keep Inngest functions relatively small.

Step 3 — Add retries

Use retries for operations that can temporarily fail.

Step 4 — Add idempotency

Especially around payments and external APIs.

Step 5 — Add structured logging

Make production debugging easier.

Step 6 — Add concurrency controls

Particularly for expensive workloads.

Step 7 — Add automated tests

Test important workflows before they become difficult to reason about.

Step 8 — Add staging/custom environments

Once multiple people or deployments are involved.

Step 9 — Set up production monitoring

Learn to use the Inngest dashboard rather than relying only on application logs.

Step 10 — Consider more advanced workflow features

Once the basics feel comfortable, look at:

cron jobs
delayed execution
step.sleep()
step.waitForEvent()
step.invoke()
batching
concurrency
throttling
rate limiting
cancellation
retries
metadata
durable endpoints

44. A note about the Inngest portal

When you move beyond local development, don't think of the Inngest dashboard as just another admin page.

It becomes part of your operational workflow.

A typical debugging session might look like this:

Customer reports something went wrong
              ↓
Find the relevant function
              ↓
Find the run
              ↓
Inspect event payload
              ↓
Open execution trace
              ↓
Find failed step
              ↓
Inspect retry attempts
              ↓
Fix application
              ↓
Deploy
              ↓
Rerun the function

The dashboard's run details are designed specifically for this kind of investigation.

And because Inngest automatically traces function runs, you don't need to build your own complete workflow tracing system just to understand what happened.

45. One last architectural picture

If you remember nothing else from this guide, remember this:

                    NEXT.JS
                       │
             ┌─────────┴─────────┐
             │                   │
          Request             Event
             │                   │
             │             inngest.send()
             │                   │
             ▼                   ▼
          Response            INNGEST
                                 │
                     ┌───────────┼───────────┐
                     │           │           │
                     ▼           ▼           ▼
                  Function    Function    Function
                     │
                ┌────┴────┐
                │         │
              Step       Step
                │         │
                ▼         ▼
              DB/API   Email/CRM

Next.js handles your application.

Inngest handles the durable background execution.

Your functions describe workflows.

Steps divide those workflows into retryable units.

And the dashboard lets you see what actually happened.

46. Final checklist

Before calling your Inngest setup complete, check these:

[ ] inngest is installed
[ ] src/inngest/client.ts exists
[ ] Functions live under src/inngest/functions/
[ ] Every function has a stable ID
[ ] Functions have event triggers
[ ] /api/inngest exists
[ ] serve() includes all your functions
[ ] INNGEST_DEV=1 is configured for local development
[ ] Inngest Dev Server is running
[ ] You can open localhost:8288
[ ] You can send a test event
[ ] The function appears in the Dev Server
[ ] You can inspect a successful run
[ ] You can intentionally trigger an error and inspect the failure
[ ] Important side effects are inside step.run()
[ ] Production has an Event Key
[ ] Production has a Signing Key
[ ] Secrets aren't committed to Git
[ ] You have considered idempotency
[ ] You have considered retries
[ ] You have a plan for production monitoring

Conclusion

The nice thing about Inngest is that you don't have to think of it as "another queue system."

A better way to think about it is:

Inngest lets you describe reliable background work as code.

You publish an event:

await inngest.send({
  name: "app/user.created",
  data: {
    userId,
  },
});

A function reacts:

inngest.createFunction(...)

And the actual work is broken into durable steps:

await step.run("send-email", async () => {
  // ...
});

That simple model scales surprisingly far.

You can start with one function that sends an email and eventually end up with workflows involving retries, delays, scheduled jobs, external APIs, database operations, concurrency controls, and multiple environments — without having to build the underlying queue and workflow infrastructure yourself.

The most important thing is not to rush into every advanced Inngest feature.

Start small.

Get this working:

Event
  ↓
Function
  ↓
Step
  ↓
Result

Then open the Dev Server, break something deliberately, watch the failed run, fix it, and rerun it.

Once that workflow makes sense, the rest of Inngest becomes considerably easier to understand.

For the latest SDK details, especially around v4 APIs and deployment configuration, keep the official Inngest documentation nearby because the platform and SDK continue to evolve.

Stream your movies to VLC across devices with this simple FTP Server with python.

Ishan Jarwal — Wed, 22 Jul 2026 15:10:12 +0000

Sometimes you just need to move a few files between machines on your local network.

You don't want to configure a full FTP daemon, create system users, edit configuration files, and set up a permanent service. You just want to share a directory, grab the files from another machine, and shut the server down when you're finished.

Python makes this surprisingly easy with pyftpdlib.

Unlike HTTP, Python doesn't ship with a built-in FTP server. If you've used:

python -m http.server

you might expect something similar for FTP. There isn't an FTP equivalent in Python's standard library, but pyftpdlib fills that gap nicely.

For temporary development environments, home networks, VMs, and quick file transfers, it's often all you need.

Installing pyftpdlib on Arch Linux

On Arch Linux, installing packages globally with pip isn't generally the best idea because the system Python environment is managed by pacman.

There are two sensible ways to install pyftpdlib.

Option 1: Install with Pacman

If the package is available in your configured repositories, this is the simplest approach:

sudo pacman -S python-pyftpdlib

Once installed, you can invoke it directly through Python:

python -m pyftpdlib

Option 2: Use a Virtual Environment

For something temporary—or if you prefer keeping Python packages isolated—a virtual environment works well:

python -m venv .venv
source .venv/bin/activate
pip install pyftpdlib

Then start the server with:

python -m pyftpdlib

When you're finished, leave the environment with:

deactivate

The Simplest FTP Server

Suppose you're inside a directory containing files you want to share:

cd ~/Downloads

Start the server:

python -m pyftpdlib

That's it.

pyftpdlib starts an FTP server and exposes the current working directory.

You'll see output indicating the address and port the server is listening on.

By default, this is useful primarily as a quick anonymous FTP server. Anonymous users are restricted to downloading files rather than modifying the directory.

Sharing a Specific Directory

You don't actually have to cd into the directory first.

You can tell pyftpdlib exactly which directory should become the FTP root:

python -m pyftpdlib -d ~/Downloads

This is particularly useful when you're running the command from scripts or another working directory.

For example:

python -m pyftpdlib -d ~/Videos

Now clients connecting to the FTP server will see the contents of ~/Videos.

Choosing the Port

FTP traditionally uses port 21.

On Linux, however, ports below 1024 normally require elevated privileges. Running an entire temporary Python FTP server as root just to get port 21 isn't a great trade-off.

Instead, use a higher port such as 2121:

python -m pyftpdlib -p 2121

Or combine it with a directory:

python -m pyftpdlib -p 2121 -d ~/Downloads

I generally prefer 2121 for temporary FTP servers because it makes the purpose obvious while avoiding root privileges.

Setting a Username and Password

Anonymous access is convenient, but you probably don't want everyone on your network accessing the directory.

pyftpdlib lets you specify credentials directly from the command line.

For example:

python -m pyftpdlib \
    -u ishu \
    -P 'my-password' \
    -p 2121 \
    -d ~/Downloads

Here:

-u ishu sets the FTP username.
-P 'my-password' sets the password.
-p 2121 runs the server on port 2121.
-d ~/Downloads makes ~/Downloads the FTP root.

A client would then connect using:

Username: ishu
Password: my-password

One thing worth remembering: putting passwords directly into commands can leave them in your shell history. That's fine for disposable local credentials, but don't reuse an important password here.

Allowing File Uploads

So far, we're mainly using FTP to download files.

Sometimes the opposite is more useful. Maybe you want to quickly send files from your phone or another computer back to your Arch machine.

Enable write access with:

python -m pyftpdlib -w

Combined with authentication and a specific directory:

python -m pyftpdlib \
    -u ishu \
    -P 'temporary-password' \
    -w \
    -p 2121 \
    -d ~/Downloads

The -w flag enables write operations, allowing clients to upload and modify files.

Be more careful with this option. Anyone who obtains the credentials may be able to modify files inside the shared directory.

For temporary transfers, I like creating a dedicated directory:

mkdir -p ~/ftp-share

Then expose only that directory:

python -m pyftpdlib \
    -u ishu \
    -P 'temporary-password' \
    -w \
    -p 2121 \
    -d ~/ftp-share

That way you're not accidentally exposing your home directory or something more important.

Making the Server Reachable from Other Devices

If you're connecting from another computer, binding only to localhost won't help. The server needs to listen on an interface reachable from your network.

You can explicitly bind it to all interfaces:

python -m pyftpdlib \
    -i 0.0.0.0 \
    -p 2121 \
    -d ~/ftp-share

With authentication and uploads enabled, a more complete command becomes:

python -m pyftpdlib \
    -i 0.0.0.0 \
    -p 2121 \
    -u ishu \
    -P 'temporary-password' \
    -w \
    -d ~/ftp-share

Now you need the local IP address of your Arch machine.

One quick way to find it is:

ip addr

Or:

hostname -I

Suppose your machine is:

192.168.1.42

Your FTP server would then be reachable at:

ftp://192.168.1.42:2121

from other devices on the same network, assuming your firewall and network configuration allow the connection.

Connecting with curl

You don't necessarily need a graphical FTP client.

curl works perfectly well for quick transfers.

List the files available on the server:

curl ftp://192.168.1.42:2121/

With authentication:

curl -u ishu ftp://192.168.1.42:2121/

curl will prompt for the password instead of forcing you to put it directly in the command.

Download a file:

curl -u ishu \
    ftp://192.168.1.42:2121/example.zip \
    -o example.zip

If write access is enabled, upload a file:

curl -u ishu \
    -T photo.jpg \
    ftp://192.168.1.42:2121/

Connecting with an FTP Client

You can also use a traditional command-line FTP client:

ftp 192.168.1.42 2121

Enter the username and password when prompted.

Graphical clients such as FileZilla work as well. You'd configure roughly:

Host: 192.168.1.42
Port: 2121
Protocol: FTP
Username: ishu
Password: your temporary password

A Command Worth Remembering

For a temporary authenticated FTP drop folder, the command I find most useful is:

python -m pyftpdlib \
    -i 0.0.0.0 \
    -p 2121 \
    -u ishu \
    -P 'temporary-password' \
    -w \
    -d ~/ftp-share

It gives you a specific shared directory, a non-privileged port, authentication, upload support, and access from other devices on your network.

Once the transfer is finished, press:

Ctrl+C

and the server disappears.

No daemon to disable. No service left running in the background. No permanent FTP configuration to maintain.

A Few Security Notes

This setup is best thought of as a temporary file-transfer tool, particularly on a trusted local network.

Traditional FTP does not encrypt credentials or file transfers. Don't expose this server directly to the public internet, and don't use a password that you use elsewhere.

For transfers across untrusted networks, SSH/SFTP is usually the better choice:

sftp username@server

If all you need is downloading files without authentication or uploads, Python's built-in HTTP server may be even simpler:

python -m http.server 8000 --directory ~/ftp-share

The interesting thing about pyftpdlib isn't that it replaces a proper FTP server. It doesn't need to.

Its value is that when you need an FTP server right now, for one directory and perhaps only ten minutes, you can have one running before you'd normally finish editing the configuration file for a traditional FTP daemon.

Using Ventoy to create bootable device with multiple OS disk images.

Ishan Jarwal — Tue, 02 Jun 2026 07:53:31 +0000

Ventoy lets you create a multi-boot USB drive where you can simply copy ISO files directly (Windows, Linux, etc.) without reformatting or re-burning each time.

Step 1: Install Ventoy in Arch Linux

You can install it via the AUR.

yay -S ventoy-bin

(If you don’t have yay, install it or use another AUR helper like paru.)

Alternatively, you can manually download it:

git clone https://aur.archlinux.org/ventoy-bin.git
cd ventoy-bin
makepkg -si

Step 2: Identify Your USB Drive

Plug in your USB stick and list your disks:

lsblk

// Shows something like this 

sda    500G  HDD
sdb    16G   USB Drive

So here the USB is /dev/sdb.

Step 3: Install Ventoy on the USB

Run Ventoy to install the bootloader on the USB:

sudo ventoy -i /dev/sdX

You’ll get a confirmation prompt, type y to proceed.

To update Ventoy in the future without erasing files:

sudo ventoy -u /dev/sdX

Step 4: Add ISO Images

Once installed, Ventoy creates two partitions:

A small Ventoy system partition
A large exFAT partition (visible in file manager)

You can now mount the USB and copy any .iso, .img, or .wim files directly into it, e.g.:

cp ~/Downloads/archlinux.iso /run/media/$USER/Ventoy/
cp ~/Downloads/ubuntu.iso /run/media/$USER/Ventoy/

Step 5: Boot from Ventoy USB

Reboot your system.
Enter your boot menu (usually F12, Esc, or F8 depending on your BIOS/UEFI).
Select your Ventoy USB device.
Ventoy menu will appear with a list of all ISO images on the USB.

Use arrow keys to choose the OS you want to boot and hit Enter.

Optional Features

Persistence (for live Linux distros): You can create a persistence file and attach it:

  sudo ventoy -c

Secure Boot Support: Ventoy supports Secure Boot, you can enable it:

  sudo ventoy -g /dev/sdX

Tips

You can rename ISOs for clarity — Ventoy reads their labels dynamically.

If you add or remove ISOs, you don’t need to “refresh” anything — just copy them in/out.

Works perfectly with both BIOS and UEFI boot modes.

How to download Youtube Videos & Playlists with yt-dlp (100% Free)

Ishan Jarwal — Tue, 02 Jun 2026 07:51:54 +0000

This is a short tutorial on how to download an entire youtube playlist with just one command line with yt-dlp, an open source package, No ads, No subscriptions.

Step 1 : Install yt-dlp

To install the package, use wget

wget https://github.com/yt-dlp/yt-dlp/releases/latest/download/yt-dlp -O yt-dlp

Step 2: Make it executable and move to PATH

chmod +x yt-dlp
sudo mv yt-dlp /usr/local/bin/

Test the installation :

yt-dlp --version

Step 3: Install ffmpeg (needed for mp3 conversion)

sudo pacman -S ffmpeg

Download with a single line :

Option / Format	Command Example
Download video (default, best quality)	`yt-dlp <URL>`
Download best video + audio (merge mp4/mkv)	`yt-dlp -f "bestvideo+bestaudio" <URL>`
Extract audio only (default format)	`yt-dlp -x <URL>`
Extract audio as MP3	`yt-dlp -x --audio-format mp3 <URL>`
Extract audio as WAV	`yt-dlp -x --audio-format wav <URL>`
Download entire playlist as MP3 (with track numbers)	`yt-dlp -x --audio-format mp3 -o "%(playlist_index)02d - %(title)s.%(ext)s" <PLAYLIST_URL>`
Save inside folder named after playlist	`yt-dlp -x --audio-format mp3 -o "%(playlist_title)s/%(playlist_index)02d - %(title)s.%(ext)s" <PLAYLIST_URL>`
Download specific items from playlist (e.g. 1–10, 15, 20)	`yt-dlp --playlist-items 1-10,15,20 <PLAYLIST_URL>`
Download subtitles (if available)	`yt-dlp --write-subs --sub-lang en <URL>`
Embed metadata (artist, album, thumbnail, etc.) into MP3	`yt-dlp -x --audio-format mp3 --embed-metadata --embed-thumbnail <URL>`
Set custom output filename	`yt-dlp -o "%(title)s.%(ext)s" <URL>`

And that's a wrap

Abandoned project came alive | I built and shipped my first SaaS

Ishan Jarwal — Sat, 30 May 2026 18:35:01 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

I Finally Finished the Side Project That Refused to Die

What I Built

Tonight, I finally deployed a project that has been sitting in my "I'll finish it someday" folder for far too long.

It's called Resumazing, an AI-powered Resume Builder SaaS that helps users create professional resumes with AI assistance, ATS analysis, resume scoring, job fit analysis and multiple resume management features.

What started as a weekend experiment slowly turned into a real product. Every time I thought it was almost done, I found another feature to build, another bug to fix, or another UI improvement to make.

At several points, I considered abandoning it and moving on to the next shiny idea. But this I got the push I needed to finally cross the finish line.

Demo

Live Demo: https://resumazing.vercel.app

The Comeback Story

This project wasn't abandoned because it was broken.
It was abandoned because it was almost finished.
And honestly, that's the hardest stage.

The core functionality already worked months ago, but there were dozens of unfinished details:

Authentication improvements
Resume templating issues
Better validation and error handling
UI polish
Performance fixes
Deployment setup
Countless small bugs

The project sat untouched while I learned new technologies, started new ideas, and kept telling myself I'd come back to it later.

This week, I finally did.

I stopped adding features, focused on completing what already existed, and pushed through the final stretch.

A few hours later, the deployment was live.
Not perfect. Not finished forever.
But finished enough to be used by real people.

And that's a much better place for a project than sitting in a local folder.

Tech I used

I built it on nextjs with industry best practices like precommit scripts with husky, ensuring typesafety all over, writing maintainable code.
I used the follwing :

inngest - for background jobs
dodopayments - for payments and subscription lifecycle handling
@react-pdf/renderer - for making templates
zustand - for state management
zod - for validations
cloudinary - for object storage
react-hook-forms - for form state handling
and many more packages

Find the project here : https://github.com/ishanjarwal/resume-builder-saas

My Experience with GitHub Copilot

GitHub Copilot was surprisingly helpful during the finishing phase.

The hardest part wasn't building new features, it was dealing with all the small tasks that come with polishing a project:

Refactoring code
Generating repetitive boilerplate
Fixing type issues
Writing validation logic
Explaining unfamiliar APIs

For me, Copilot worked best as a development partner rather than an autopilot.

Final Thoughts

Starting projects is exciting.
Finishing them is difficult.

This project taught me that most side projects don't fail because the idea is bad—they fail because the final 10% takes longer than the first 90%.

Tonight, I finally shipped mine.
And honestly, that feels pretty good...

Installing PostgreSQL on Arch Linux | Practical Setup Guide

Ishan Jarwal — Sat, 30 May 2026 17:57:25 +0000

Installing postgres on windows/mac is pretty simple, you just follow the steps on the installation wizard and you get it working. You will also find lots of video tutorials and blogs regarding installation in windows/mac.

But when it comes to linux (specifically arch), things get interesting. Since linux gives you more control, setting up anything on it can seem tricky at first glance but as you go through, you understand each and every step and its purpose.

Before getting into it, understand this : Postgres is not like MongoDB which you initialize once through the CLI by providing the --dbpath flag, it is a system service. Meaning it will run on the system 24x7 (if we configure it that way) and different system users will be able to use it according to the access they have been granted.

First things first : Installation

Always update the packages first :

sudo pacman -Syu

Install PostgreSQL:

sudo pacman -S postgresql

Lets initialize a Database Cluster

PostgreSQL requires a data directory initialization. This is the directory which holds the actual data (one-time step unlike MongoDB) :

sudo -u postgres initdb -D /var/lib/postgres/data

Flags explained

-u postgres → run command as postgres system user initdb → creates system tables & internal structure -D → data directory location

Start & Enable Service

Start server:

sudo systemctl start postgresql

Enable on every boot :

sudo systemctl enable postgresql

Check status:

systemctl status postgresql

Enter psql Shell

What is psql ? It is a command line interface to interact with out postgres service, databases, relations etc.

Lets enter the psql shell with the user “postgres”.

On installing postgres, a new user named “postgres” is generated with default privileges.

sudo -u postgres psql

Why no password?

Default auth configuration is the “peer” auth. Peer auth uses our OS user to login
OS user identity is trusted

Create Role for a Project

It is always a good practice to create a separate role for every major project. This way you follow modular principles.

Inside psql:

CREATE ROLE myapp WITH
  LOGIN
  PASSWORD 'devpass123'
  CREATEDB;

Meaning:

LOGIN → allows authentication
PASSWORD → required for apps/ORMs
CREATEDB → grant access to create databases

Create a Database

CREATE DATABASE myapp_db OWNER myapp;

Ownership = full control over that DB.

Some frequently used and useful psql Commands

List Databases

\l

List roles (users)

\du

List tables/relations

\d

Show current connection details

\conninfo

Show the active role

SELECT current_user;

Connection URL Format

To connect to the database, you will need a url (Yes this is the one you add in your environment variables)

General structure : postgresql://USER:PASSWORD@HOST:PORT/DATABASE

Example : postgresql://myapp:devpass123@localhost:5432/myapp_db

This url can be used by:

Prisma
ORMs
Drivers
CLI tools

Enable Password Authentication (Critical for Prisma)

Edit config:

sudo nano /var/lib/postgres/data/pg_hba.conf

Change these lines according to your needs :

local   all   all                 md5
host    all   all   127.0.0.1/32  md5
host    all   all   ::1/128       md5

Replace md5 with one of the following :

trust → no password
peer → OS identity
md5 / scram-sha-256 → password-based login

Restart PostgreSQL

To apply the config changes :

sudo systemctl restart postgresql

Testing our Connection

psql "postgresql://myapp:devpass123@localhost:5432/myapp_db"

psql -U myapp -d myapp_db -h localhost -W

Flags explained

-U → database role -d → database name -h → host (forces TCP) -W → force password prompt

Some Common Errors & Causes you might face

password authentication failed → wrong password
database does not exist → DB missing
role does not exist → user missing
could not connect to server → service stopped / wrong port

Again, remember

PostgreSQL:

Always-running service
Config-driven behavior
URL = connection info only

No manual server start like MongoDB.

Happy building 🚀

Git Rebase vs Reset vs Revert | When to use What ?

Ishan Jarwal — Fri, 29 May 2026 12:54:04 +0000

The Scenario: "Oops, I Made a Messy Commit History"

Imagine you're working on a feature branch called feature/login-page. You’ve made a few commits, but now :

One of the commits has a bug.
Another commit has a wrong commit message.
Your commit history looks like a jumbled mess compared to main.

Time to clean it up! But… should you rebase, reset, or revert?

First, Let’s Understand the Core Idea of Each:

Command	What it Does	Safe for Shared Branches?
`rebase`	Rewrites commit history to make it linear and clean	No, unless used carefully
`reset`	Moves the HEAD and branch pointer to a different commit	No, dangerous on shared branches
`revert`	Creates a new commit that undoes a previous commit	Yes, safe to fix public history

1. Git Rebase : "Let’s Rewrite History Neatly"

What is it?

git rebase allows you to move or "replay" your commits onto another branch or rearrange them to make a clean, linear history.

When to Use?

You want to clean up messy commit history before merging.
You want to squash commits.
You want to change commit messages.

Example:

You have these commits in feature/login-page:

A — B — C — D  (feature/login-page)         
        ↑       
      Buggy commit (C)

You want to fix commit C and clean up the message in D.

Solution: Interactive Rebase

git rebase -i HEAD~3

You’ll see something like this:

pick abc123 B pick def456 C pick ghi789 D

You can now:

Change "pick" to "edit" for C to fix the bug.
Change "pick" to "reword" for D to fix the commit message.
Squash commits if needed.

Important:

This rewrites commit hashes.
If your branch is pushed and shared, rebasing can mess up others' history. Use with care!

2. Git Reset : "Let’s Go Back in Time (Dangerously Powerful)"

What is it?

git reset moves your branch pointer (HEAD) to a previous commit. It can unstage files, remove commits, or even delete code changes.

Types of Reset:

Command	What happens?
`git reset --soft`	Keeps your changes staged.
`git reset --mixed`	Unstages changes but keeps them in the working directory.
`git reset --hard`	Deletes your changes completely. Dangerous!

When to Use?

You made local commits you don’t want anymore.
You want to uncommit but keep the changes.

Example:

You made two useless commits on top of main and want to remove them.

A — B — C — D  (main)              
            ↑            
            Your branch (HEAD)

To undo D and C:

git reset --soft HEAD~2

Your changes are still there but unstaged (due to --soft flag).
If you want to kill the changes, do

git reset --hard HEAD~2

After that your git timeline will look like this :

A — B  (main)
    ↑            
    Your branch (HEAD)

Important:

Never reset a branch that is already pushed and shared with others.
Resetting can permanently lose work (especially --hard).

3. Git Revert : "The Safe Undo Button"

What is it?

git revert creates a new commit that undoes the changes of a previous commit. It preserves history.

When to Use?

You want to undo a bad commit in a shared branch.
You want to keep history intact but fix a mistake.

Example:

Commit C introduced a bug. But you’ve already pushed it to origin/main.

A — B — C — D  (main)           
             ↑            
            Bug lives here

You can revert C safely:

git revert <commit-hash-of-C>

Git will create a new commit :

A — B — C — D — E  (main)                    
                ↑                 
              "Revert C"

Important:

Safe for shared/public branches.
Doesn’t remove the commit but inverts its changes.

Quick Summary: When to Use What?

Command	Use When…
`git rebase`	You want to rewrite and clean history (local-only).
`git reset`	You want to remove commits or unstage changes locally.
`git revert`	You need to undo commits safely in shared branches.

Visual Cheat Sheet

"I messed up a commit and want to fix it before pushing" → Rebase / Reset (local only)
"I pushed a bad commit, now I need to undo it on remote" → Revert
"I made several ugly small commits, want to squash them" → Rebase -i

Final Tips

Never rebase or reset public history unless you know what you’re doing.
Use git log --oneline --graph to visualize the history before making changes.
Always backup your branch with git branch backup/my-branch before risky operations.

Learn Package Management on Arch Linux: pacman & yay

Ishan Jarwal — Fri, 29 May 2026 07:59:48 +0000

Part 1: Understanding `pacman`

pacman is the default package manager for Arch Linux. It directly interacts with the official repositories and handles installation, updates, and removal of software.

Basic Syntax

sudo pacman [options] [package_name]

Common pacman Commands

Task	Command	Description
Update package database and system	`sudo pacman -Syu`	Sync package list (`-Sy`) and upgrade all packages (`-u`).
Install a package	`sudo pacman -S <package>`	Installs package from official repo.
Remove a package	`sudo pacman -R <package>`	Removes a package (keeps dependencies).
Remove a package and its unused dependencies	`sudo pacman -Rns <package>`	Clean uninstall — removes package, configs, and dependencies.
Search for a package	`pacman -Ss <keyword>`	Search available packages.
List installed packages	`pacman -Q`	Shows all installed packages.
Show package info	`pacman -Qi <package>`	Displays metadata (version, size, dependencies).
Clean cache	`sudo pacman -Sc`	Removes old packages from cache.

Official Reference:

Pacman Manual - ArchWiki

🧹 Pro Tip

To free up space, remove unused dependencies and old cached packages:

sudo pacman -Rns $(pacman -Qdtq)
sudo pacman -Scc

Part 2: Using `yay` for AUR Packages

The Arch User Repository (AUR) contains community-maintained build scripts (PKGBUILDs) for software not in the official repositories.

yay (Yet Another Yaourt) is a lightweight, fast, and user-friendly AUR helper that automates the build and installation process.

Basic Syntax

yay [options] [package_name]

Common yay Commands

Task	Command	Description
Update everything (official + AUR)	`yay -Syu`	Sync and upgrade both official and AUR packages.
Install an AUR package	`yay -S <package>`	Automatically fetches, builds, and installs from AUR.
Search for AUR packages	`yay -Ss <keyword>`	Search both official and AUR repositories.
Remove a package	`yay -Rns <package>`	Same as pacman — removes package + unused dependencies.
Clean build cache	`yay -Sc`	Clean yay’s build directory.
List all AUR packages	`yay -Qm`	Shows all manually installed (AUR) packages.
Check for outdated AUR packages	`yay -Qua`	Lists AUR updates available.

💡 Tip: Unlike pacman, yay doesn’t need sudo for most operations until the build process actually installs system files — it will prompt automatically.

Official Reference:

Yay GitHub Repository

Flag Summary

Flag	Tool	Meaning
`-S`	pacman/yay	Install package(s)
`-R`	pacman/yay	Remove package(s)
`-Ss`	pacman/yay	Search package in repos
`-Qi`	pacman	Show package info
`-Qm`	yay	List manually installed (AUR) packages
`-Syu`	pacman/yay	Sync database and upgrade all packages
`-Rns`	pacman/yay	Remove package + dependencies + configs
`-Sc`	pacman/yay	Clean package cache
`-Qdtq`	pacman	List orphaned packages

A Comprehensive and Comfy Guide to Git.

Ishan Jarwal — Fri, 29 May 2026 07:47:15 +0000

Git is not just a tool; it’s a life-saver for developers. It helps you track changes, collaborate with others, and never lose your work. This guide is designed to be a comfy walkthrough of Git , not too heavy on jargon, but packed with useful knowledge.

A Tiny History of Git and Why You Should Care

Git was created by Linus Torvalds in 2005, the same genius who built Linux. It was born out of necessity when the Linux community needed a version control system that was fast, distributed, and free.

Today, Git powers everything from hobby projects to massive codebases like those at Google, Microsoft, and Facebook. Whether you're working on a personal website or contributing to open-source, Git is the industry standard.

Where is Git

Software Development (obviously!)
Documentation Projects
Collaborative Design Workflows
Versioning for Configuration Files

If it involves files that change over time, Git can manage it.

Key Git Terminologies

Repository (Repo)
A directory where your project's Git history is stored. It's like a folder, but smarter.
Staging Area
Think of this as a "waiting room" where changes sit before you officially save them in the project history.
Commit
A snapshot of your project at a specific point in time. This is how you save your work in Git.
Push
You "push" commits to a remote repository (like GitHub) so others can see your work.
Remote
A version of your project that's hosted on the internet or another network.

Setting Up Git for the First Time

Install Git
Download from git-scm.com
Configure Your Identity
Before you do anything, tell Git who you are. We do this by telling git what is our username and email

git config --global user.name "Your Name"
git config --global user.email "your.email@example.com"

Initialize a Git Repository Navigate to your project folder and run:

cd /path/to/your/project's/root
git init

This creates a .git folder in your project. If you don't know, folders starting with a "." are hidden folders so you might not see it in the folder tree. This is where the information about your codebase is saved.

Tracking Changes (Staging & Committing)

Check Project Status

git status

This shows which files have been changed, which are staged, and which are not. You will see something like this in your terminal.

Add Files to Staging Area

git add filename.txt

Or add everything:

git add .

This is one step before committing your changes. Note that the files added to the staging area are the only ones going to be committed. All other files will be "unstaged files"

Committing the Changes

git commit -m "Add feature X"

Git expects you to associate every commit with a message. After running this command, a snapshot of your staged changes will be saved as a "commit".

Viewing Commit History

git log

This shows all commits in your repo. Use q to exit log view.

The HEAD in Git points to the current snapshot (commit) you are working on. Think of it as "where you are" in your project history.

Understanding Branches

A branch in Git is like creating an alternate universe for your code where you can try out new features without disturbing the main project. I would call this the most amazing feature offered by Git. Think of it as you are working on a feature and committing the changes step by step.

Eg : Initialize Project -> create homepage -> add images -> change fonts . . .

But parallel to this workflow, you also want to create a new feature say "Authentication" in the same project and without disturbing the main flow.

When you first initialize your project, the default branch you work on is either "master" or "main"

Create a New Branch

git branch new-feature

Switch to That Branch

git checkout new-feature

Or Do Both in One Command

git checkout -b new-feature

List All Branches

git branch

Delete a Branch

git branch -d old-feature

You can learn more about "Merging Branches" from here. It is an advanced git concept, hence it will not be discussed here.

Push Your Code to GitHub

Till now, we have created our repo, some commits (our checkpoints) and also branches. But all of this resides in our local machine. If anything goes wrong your pc, all of your data will be lost. For this purpose we have "Github", a place where you can upload your code so that it stays safe.

Following theses steps you can do it easily.

Create a Github account and the repo.

First step is to create your github accout. Simply add your details, verify your account and your are good to go.
Now you can click the "Create New Repository" button, give it a name, make it public/private according to you and hit create.
Now your remote repository is created and we need to connect it to our local git project, to do that, follow these steps

Add Remote URL

git remote add origin https://github.com/yourusername/your-repo.git

here, origin is nothing but an alias for your remote repository, you can see all the aliases by this command

git remote -v

Push to Remote

git push -u origin main

This will "push" or upload our codebase to our remote repository. The "-u" flag tells Git to set the remote branch (origin/main) as the upstream (or default) branch for your local branch (main).

Congrats, your code is now safe on github.

Bonus Tips: Git in VSCode

If you prefer clicking buttons over typing commands, Visual Studio Code has an excellent Git GUI.

Must-have VSCode Git Extensions:

GitLens: Supercharge your Git experience.

Git Graph: Visualize your branches and commits.

GitHub Pull Requests and Issues: Manage PRs from within VSCode.

What's Next?

This guide covers the comfy essentials to get you started. In the next post, we'll explore advanced Git concepts like merge conflicts, rebasing, reverting commits, and more.

For now, get your hands dirty and start committing!

That's it! You're now Git-ready.

DEV Community: Ishan Jarwal

Asynchronous Jobs made easy with Inngest | Learn how to setup Inngest in a Typescript Project

Inngest with Next.js and TypeScript: A Practical Guide to Background Jobs, Workflows, Retries, and Debugging

What we're going to build

1. First, what problem is Inngest actually solving?

2. When should you use Inngest?

3. Prerequisites

4. Install Inngest

5. The folder structure

6. src/inngest/client.ts

7. Create your first Inngest function

8. Export your functions

9. Create the Inngest API route

10. Your project should now look something like this

11. Run the Inngest Dev Server

12. Run Next.js in development mode

13. Trigger your first event

14. A more realistic example

15. Why step.run() matters

16. Don't put important side effects outside steps

17. Retries

18. Sleeping without keeping a server request open

19. A complete workflow example

20. Environment variables

21. Event Key vs Signing Key

Event Key

Signing Key

22. What happens in production?

23. Deploying with Vercel

24. Inngest environments

25. The Inngest Portal / Dashboard

26. Debugging locally

27. Debugging production failures

28. Use meaningful step IDs

29. Logging

30. A note about retries and duplicate side effects

31. Don't make one giant step

32. But don't create a step for every line either

33. Sending multiple events

34. Event naming conventions

35. Cron jobs

36. Concurrency and throttling

37. Testing Inngest functions

38. Keep business logic separate from Inngest

39. A clean final folder structure

40. A complete example

src/inngest/client.ts

src/inngest/functions/user-created.ts

src/inngest/functions/index.ts

src/app/api/inngest/route.ts

.env.local

41. The mental model I recommend

1. Event

2. Function

3. Step

4. Serve

5. Dev Server / Dashboard

42. Common mistakes

Mistake #1: Forgetting the /api/inngest route

Mistake #2: Running the wrong environment

Mistake #3: Hard-coding secrets

Mistake #4: Putting side effects outside steps

Mistake #5: Making one enormous step

Mistake #6: Ignoring idempotency

Mistake #7: Using meaningless function IDs

43. What I'd do next in a real project

Step 1 — Create a proper event naming convention

Step 2 — Move business logic into services

Step 3 — Add retries

Step 4 — Add idempotency

Step 5 — Add structured logging

Step 6 — Add concurrency controls

Step 7 — Add automated tests

Step 8 — Add staging/custom environments

Step 9 — Set up production monitoring

Step 10 — Consider more advanced workflow features

44. A note about the Inngest portal

45. One last architectural picture

46. Final checklist

Conclusion

6. `src/inngest/client.ts`

15. Why `step.run()` matters

`src/inngest/client.ts`

`src/inngest/functions/user-created.ts`

`src/inngest/functions/index.ts`

`src/app/api/inngest/route.ts`

`.env.local`

Mistake #1: Forgetting the `/api/inngest` route