Technology

NestJS deployment for APIs that serve web and mobile

Structuring a NestJS backend is the easy part. Keeping it running needs a database, a container image, a server with proxy and certificate, and a view on errors. The platform sets that up.

Production-ready NestJS template with repository and project structure
Database, Docker, reverse proxy, SSL, firewall and backups configured automatically
One API for web frontends and mobile clients from the same project

Start for free. No credit card required.

acme / customer-app

kunden-app
Flutter app for iOS, Android, and web
backend
API and server logic with Docker setup
homepage
Marketing site and public content
e2e-tests
End-to-end tests against dev and staging
gitops-configuration
Deployment configuration for dev and prod
local-configuration
Workspace, IDE, and agent configuration
gitlab-profile
Project documentation and README

Repository, deploy keys and CI variables are created when the project starts.

In short

NestJS gives your backend structure. What it does not give you is the environment around it, and that is what the platform sets up.

The template produces a repository, a project structure and a GitLab CI pipeline.
The server side arrives with Docker, a database, reverse proxy, SSL, firewall and backups.

Setting up NestJS yourself versus running it on the platform

A look at the work a hand-built backend environment involves and how much of it the platform takes over.

Task	With the Application Platform	Set up yourself
Project structure and repository	Fully covered: Generated from a production-ready NestJS template with settled conventions	Not offered: Create the repository, decide the module layout, agree conventions
Build and deployment pipeline	Fully covered: GitLab CI pipeline for test, build, publish and release comes with the project	Not offered: Write the pipeline, provision runners, work out caching and artefacts
Container image and rollout	Fully covered: The image is built in CI, published and rolled out to the target server	Not offered: Maintain the Dockerfile, registry, credentials and rollout yourself
Database	Fully covered: MySQL is provisioned during server setup, backups included	Not offered: Install and harden the database, create users, plan the backups
Exposing the API publicly	Fully covered: Reverse proxy, domain and SSL are part of the setup	Not offered: Configure the proxy, issue and renew certificates
Credentials and environment variables	Fully covered: Central to the project, separated per environment, handed to pipeline and runtime	Partly covered: Spread across CI variables, files on servers and local copies
Web and mobile clients	Fully covered: A Next.js frontend and a Flutter app can live in the same project	Partly covered: Separate setups with their own pipelines, servers and secrets
Shared NPM packages	Fully covered: Built and published in CI, with access rights set per project	Partly covered: Run your own registry or copy code between repositories
Errors in production	Fully covered: Sentry is fully configured, errors arrive with stack trace, release and context	Partly covered: Search logs or integrate error tracking yourself
Traceability of environments	Fully covered: Environments and deployments live as configuration in the Git history	Not offered: Server state accumulates over time and is rarely documented

Green means fully covered, amber partly, grey still on you. None of it is unsolvable, it simply costs time that never reaches the API.

As of 10 August 2026. This comparison describes typical workflows and can differ from project to project.

What you get for NestJS specifically

The pieces a TypeScript backend needs once real clients depend on it.

Production-ready template

The NestJS template brings structure, conventions and a working setup. A whitelabel variant exists for multi-brand products.

Database and server baseline

Docker, MySQL, reverse proxy, SSL, firewall and backups are configured automatically, on your own machines as well as managed ones.

Pipeline in the repository

Test, build, publish and release run through GitLab CI configuration that sits readable in your repository and can be edited.

One API for every client

Sentry is set up end to end. Exceptions arrive with a stack trace, the affected release and context instead of a single log line.

Pipeline for Customer App

test

build

publish

release

Test, build and release follow the same path as on the frontend.

Getting your NestJS backend live

Four steps from creating the project to a reachable API.

Connect a server

Your own machine over SSH or a managed server. Docker, database, reverse proxy, SSL, firewall and backups get configured.
Create the project from the template

Pick NestJS in the wizard. Repository, project structure and CI/CD pipeline are created alongside the project.
Move code and credentials in

Bring your existing modules into the repository and store environment variables and credentials centrally in the project.
Deploy and connect the clients

A push starts the pipeline. Once the API answers on its domain, you point your web frontend and mobile app at it.

Frequently asked questions

Which database does the NestJS template use?

The backend templates work with MySQL, provisioned as part of the server setup. Credentials live centrally in the project and are handed to the application at runtime. Backups belong to the server baseline.

Can frontend, app and backend live in the same project?

Yes. A project can hold several applications, for instance a NestJS backend, a Next.js frontend and a Flutter app. Each has its own repository and pipeline while sharing project configuration, server connection and credentials.

How do I share types between backend and clients?

Usually yes. NestJS runs as an ordinary Node process in a container, with no proprietary runtime layer. You move code and environment variables into the generated project. Adjustments are needed where deployment scripts were hard-wired.

Create a NestJS project and deploy it