# Deploying applications

Preparing a build, deploying it and verifying the result.

> Section: Applications

## Prepare the build

Next.js needs output: 'standalone' in next.config. NestJS uses dist/main.js. A custom Node application needs a runnable server entrypoint. In every case the application must bind the PORT it is given rather than a hardcoded one.

## Deploy

Run the command in your application directory and pass the project ID. Choose nextjs, nestjs or custom to match your project.

```bash
veltic apps deploy PROJECT_ID storefront ./ --framework nextjs
veltic apps logs PROJECT_ID storefront --follow
```

## How a deployment actually replaces the old one

The running container is stopped and renamed to a rollback container. The new one starts and is probed over HTTP. Only after the probe passes is the old container discarded; if the probe fails, the previous version comes back. There is a brief interruption during the swap, so this is not a rolling reload.

## The runtime you get

A rootless Podman container with a read-only root filesystem, all capabilities dropped, no new privileges, a process limit and a hard memory limit without swap. Exceeding memory is a kernel kill, not a graceful restart, and the restart policy retries a bounded number of times.

- Persistent data belongs in the database or storage, never on the container filesystem.
- Secrets are environment variables, configured per application.
- Logs stream over a realtime channel; the dashboard no longer polls.