# Security

> What nextship can reach, how each credential is handled, and the exposures that are properties of the design.

Source: https://nextship.doodlebytestudio.in/docs/security

nextship runs on your machine or in your CI with your cloud credentials. It is worth
knowing exactly what that means, because the honest answer is "quite a lot".

## What it reads

- Your `DIGITALOCEAN_TOKEN`, which speaks for your whole account within its scopes
- Your project's env files, including secrets, which it mounts into a Docker build
- Your project's source, which it builds inside a container

> **Note:** **It never sends your code anywhere except your own cloud account or your own server.** There is
> no nextship server, nothing is collected, and there is no telemetry.

That is the CLI. This website, separately, counts page views with Cloudflare Web Analytics,
which sets no cookies and does not follow you to other sites.

## How credentials are handled

| Secret | Handling |
|---|---|
| `DIGITALOCEAN_TOKEN` | Read from the environment. Written to a temporary Docker config directory with `0600` permissions for `docker push`, then removed, so it never appears in a process argument list where other local processes could read it |
| Env files | Mounted as BuildKit secrets, excluded from image layers and from the build cache key. Never copied into the image |
| Server Actions encryption key | Stored in `.nextship/secrets.local.json`, which nextship gitignores on creation so it cannot be committed |
| Log stream URLs | These carry an embedded access token, so they are treated as secrets: never printed, never logged, never in an error message |
| Server host keys | Pinned in `nextship.json` after the fingerprint is shown. Every connection checks strictly against the pinned key, so a changed key is refused rather than prompted about |
| SSH connections | Your own `ssh`, in batch mode with no passwords, started without a shell. nextship never reads a private key |
| Values pushed by `env push` | Redacted from any error message before it is shown, because an API validation error can quote the field it rejected |

## Known exposures, stated plainly

These are properties of the design rather than bugs. They are listed so you can decide
whether they suit your threat model.

**The built image contains your Server Actions encryption key.** Next.js compiles it into
`server-reference-manifest.json` at build time. Anyone who can pull your image can read
it, so registry access is equivalent to key access.

**Pushed environment variables are decrypted in the running container.** Your platform
encrypts them at rest, but anyone who can open a console on the app can read them.

**`nextship destroy` permanently removes an app.** It requires the app name and `--yes`,
but it is not recoverable.

## Reporting a vulnerability

Report privately through
[GitHub Security Advisories](https://github.com/gowtham472/nextship/security/advisories/new).
Please do not open a public issue.

Include what you did, what happened, and what you expected. A reproduction against a
throwaway cloud account is worth more than a description.

Expect a first reply within a week. This is a small project maintained by one person, so
that is a realistic commitment rather than an aspirational one.

## Scope

**In scope:** anything that leaks a credential, writes outside the project or the app
nextship recorded, or lets a malicious project being deployed escape the build container.

**Out of scope:** vulnerabilities in Docker, Next.js, or a cloud provider's API. Report
those upstream.