# Name resolution

> How routeup turns a CLI argument, env var, or config value into a route name.

routeup resolves the route name from the first source that is set. Every source
is used literally; routeup never appends a project or config name to an explicit
argument.

## Source precedence

```txt
1. CLI argument        routeup serve example-app
2. Environment         ROUTEUP_NAME=example-app
3. Config              "name" in routeup.json or the package.json routeup block
4. Directory basename  working directory name (last-resort fallback)
```

Flags and env override config; config provides the default. When none of the
above are set, routeup uses the basename of the current working directory as the
route name — so running from `~/projects/example-app` gives `https://example-app.localhost`
automatically without any config.

## Literal names

An explicit positional name is always the complete route name, whether it is
bare or dotted. Omit the argument when you want the environment, config, or
directory fallback.

```txt
config name = example-app

routeup serve                    -> example-app
routeup serve api                -> api
routeup serve api.example-app    -> api.example-app
routeup serve api.other          -> api.other

no env or config name, working directory = example-app:
routeup serve                    -> example-app

ROUTEUP_NAME=api routeup serve -> api        (environment name is literal)
```

## Local vs public names

This rule produces the **route** name. Locally any depth works
(`api.example-app` → `https://api.example-app.localhost`). Public hosts must be one label
under the server's namespace, so routeup normalizes dots to hyphens when
exposing (`api.example-app` → public label `api-example-app`). See
[Routes](/docs/concepts/routes) and [Tokens](/docs/concepts/tokens).