If you read my last post about controllers, you will remember one rule keep controllers thin. A controller should take the request, pass the real work to someone else and send back the answer.

So how is that "someone else"? In NestJS, it's a provider.

Providers are one of those words that sounds a lot scarier than the idea behind it. By the end of this post you will know what a provider is, what @Injectable() does, how dependency injection works, and how to fix the most common error beginners hit. We will keep building the same cats example, so it should feel familiar.

What is a provider in NestJS?

A provider is a class that NestJS can inject into other classes as a dependency.

That's it. Services, repositories, factories and helpers can all be providers. The main idea is that one class can ask for another, and NestJS runtime wires them together for you. You don't have to create objects with new and pass them around by hand.

In its simplest form, a provider is just a plain JavaScript class that you list in the provides array of a module.

The usual split looks like this:

• Controller: handles the HTTP side (routes, params, body)
• Provider (service): handles the actual logic (storing data, talking to a database, calculations)

What is a service?

A service is the most common kind of provider. It's where your application logic lives. Let's make a CatService that stores cats and returns them:

import { Injectable } from '@nestjs/common';
import type { Cat } from './interfaces/cat.interface.js';
@Injectable()
export class CatsService {
  private readonly cats: Cat[] = [];
  create(cat: Cat) {
    this.cats.push(cat);
  }
  findAll(): Cat[] {
    return this.cats;
  }
}

It is a basic class with one property (a list of cats) and two methods (create and findAll). The important part is the @Injectable() decorator on top. It attaches a bit of metadata to the class that says "Nest'S container is allowed to manage this one".

And here's the Cat interface the service uses:

export interface Cat {
  name: string;
  age: number;
  breed: string;
}

Tip: Skip the typing and let the CLI do it: nest g service cats

Using the service inside a controller

Now we can hand the work over from the controller to the service:

import { Controller, Get, Post, Body } from '@nestjs/common';
import { CreateCatDto } from './dto/create-cat.dto.js';
import { CatsService } from './cats.service.js';
import type { Cat } from './interfaces/cat.interface.js';
@Controller('cats')
export class CatsController {
  constructor(private catsService: CatsService) {}
  @Post()
  async create(@Body() createCatDto: CreateCatDto) {
    this.catsService.create(createCatDto);
  }
  @Get()
  async findAll(): Promise<Cat[]> {
    return this.catsService.findAll();
  }
}

Look at the controller now. It doesn't store anything and it doesn't know how cats are saved. It just calls the service. If you later switch from an in-memory list to a real database, the controller barely changes. That's the payoff of the split.

Notice there is no new CatsService() anywhere. The service arrives through the constructor. That's dependency injection.

How dependency injection works in NestJS

Dependancy injection sounds fancy but the idea is simple insted of a class creating the things it needs, it asks for them, and something else hands them over. In Nest, that "something else" is the framework itself.

Nest looks at the type you wrote in the constructor and gives you an instance of that type:

constructor(private catsService: CatsService) {}

This one line does two jobs.

1. The private keyword is a TypeScript shortcut called a parameter property. It creates a catsService member on the class and assigns the value for you, so you do not need to write this.catsService = catsService.
2. The CatsService type is what Nest uses to find the right provider. TypeScript emits the constructor's parameter types as metadata and Nest's container reads that metadata to decide what to supply.

By default, NestJs creates the instance once and shares it with every class that needs it. That is called the singleton scope.

The error everyone gets: "Nest can't resolve dependencies"

Sooner or later you will see this error at startup. Here's the most common cause.

Because Nest depends on the type existing at runtime the type in your constructor has to be a class. Interfaces and type aliases get erased when TypeScript compiles, so NestJS has nothing to look up.

// This will fail if AppConfig is an interface
constructor(private config: AppConfig) {}

The same thing happens if you import a class with import type, because that import is erased too. So do not use import type for classes you want Nest to inject.

If you really need to inject something that isn't a class, such as a plain config value, register it under a token and inject it with @Inject(). The custom providers chapter in the official docs covers this.

Two other things worth checking when you see this error:

• Did you add the service to the provides array of a module? (More on the below)
• Did you put @Injectable() on the service class?

Provider scopes: how long does a provider live?

By default, a provider lives as long as your app does. NestJS creates it when the app starts and destroys it when the app shuts down.

You can change that. For example, a request-scoped provider is created fresh for each incoming request. That is useful in special cases nut you won't need it at the beginning. The official docs cover it in the Injection scopes chapter.

Optional providers

Sometimes a class needs a dependency, but can live without it. A config object is a good example: if it's missing, you fall back to defaults. Mark it with @Optional():

import { Injectable, Optional, Inject } from '@nestjs/common';
@Injectable()
export class HttpService<T> {
  constructor(@Optional() @Inject('HTTP_OPTIONS') private httpClient: T) {}
}

If nothing is registered under the HTTP_OPTIONS token, Nest passes undefined instead of crashing at startup. Your class is then in charge of handling the fallback, usually by merging whatever was injected over a set of defaults.

Property based injection

Everything so far used the constructor. There's another way: put @Inject() straight on a property.

import { Injectable, Inject } from '@nestjs/common';
@Injectable()
export class HttpService<T> {
  @Inject('HTTP_OPTIONS')
  private readonly httpClient: T;
}

When is this useful? Mainly when a class extends another class. Passing dependencies up through super() in every subclass gets annoying fast. But if your class doesn't extend anything. stick with constructor injection. It makes it obvious what the class needs.

Register your provider in a module

This is the step people forget, just like registering controllers. You have to tell Nest the provider exists by adding it to the providers array in a module:

import { Module } from '@nestjs/common';
import { CatsController } from './cats/cats.controller.js';
import { CatsService } from './cats/cats.service.js';
@Module({
  controllers: [CatsController],
  providers: [CatsService],
})
export class AppModule {}

Now Nest can resolve everything CatsController needs.

Your folder structure at this point looks like this:

src/
  cats/
    dto/
      create-cat.dto.ts
    interfaces/
      cat.interface.ts
    cats.controller.ts
    cats.service.ts
  app.module.ts
  main.ts

Can I create providers manually?

Most of the time you won't need to. But if you ever do, there are two options:

• Use ModuleRef to fetch existing instances or create provides on the fly. See the Module reference chapter.
• Use a standalone application if you need providers inside bootstrap(), for example to read a config service at startup. See the standalone applications chapter.

Where to deploy your NestJS app

Running npm run start:dev on your laptop is fine for learning. At some point, though, you'll want your API online where other people can reach it.

Because Nest runs on Node.js, you need a server where you can install Node and keep a process running all the time. That's why a VPS makes more sense here than basic shared hosting, which is usually built for PHP sites and doesn't give you that kind of control.

I use Verpex VPS Hosting for this. Their unmanaged Linux VPS gives you full root access, so you pick the operating system, install the Node version you want, and set up the stack yourself. The plans run on NVMe SSD storage with dedicated resources (so you're not sharing your slice with a noisy neighbour), and there's a 99.9% uptime SLA plus round-the-clock infrastructure support. A small plan is plenty for a first NestJS project, and you can move up later if your traffic grows.

One honest warning: "unmanaged" means exactly that. Updates, firewall rules and security are your job, not theirs. If you've never touched a Linux server before, expect a bit of a learning curve. If you're comfortable with SSH and a terminal, that freedom is the whole point.

A typical first deploy looks like this: connect over SSH, install Node.js, clone your project, run npm install and npm run build, then keep it alive with a process manager like PM2.

Disclosure: this is an affiliate link. If you sign up through it, I may earn a commission at no extra cost to you.

Quick recap

Frequently asked questions

What is a provider in NestJS?

A class that can be injected as a dependency into controllers or other providers. Services, repositories, factories and helpers can all be providers.

What is the difference between a controller and a service?

A controller handles incoming requests and sends responses. A service holds the application logic and is injected into the controller.

What does @Injectable() do?

It attaches metadata to a class so Nest's container can manage it and inject it where needed.

Why do I get "Nest can't resolve dependencies"?

Usually the dependency isn't registered in a module's providers array, or the constructor type isn't a real class (for example an interface, or a class imported with import type).

Are NestJS providers singletons?

By default, yes. Nest creates one instance and shares it. You can change this with scopes, such as request-scoped providers.

Should I use constructor or property injection?

Constructor injection in almost every case. Property injection is mainly handy when a class extends another class.