> For the complete documentation index, see [llms.txt](https://docs.nxcframework.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nxcframework.net/nexus-core-docs/start-here/first-start.md).

# Your first start

What a successful startup looks like.

A framework that started correctly and one that started and did nothing look similar in a console. This is what correct looks like.

## The banner

```
[nxc_core] ready — v0.3.0, contract v2, Cfx Server build 106
```

If you do not see it, `nxc_core` did not finish starting. The lines above it will say why.

## The lines that matter

```
[INFO] nxc_core   startup.environment_valid  environment=development serverBuild=106
[INFO] nxc_core   startup.database_ready
[INFO] nxc_core   startup.signing_key_ready  source=generated
[INFO] nxc_config startup.ready              version=0.1.1
[INFO] nxc_config config.registered          fields=7 registeringResource=nxc_core
[INFO] nxc_core   config.registered          applied=7 fields=7 rejected=0
```

**The last two are the handshake**, and they should agree. `nxc_config` accepting a registration while `nxc_core` reports it refused means the two are not the versions the compatibility set names.

## Checking from the console

```
nxc_versions        every installed resource and its version
nxc_status          whether the framework is ready, and its current settings
nxc_config_status   which resources have registered settings
```

These are **console only**. Typed in game they do nothing at all, which looks identical to a broken command.

Run `nxc_versions` first. If the versions do not all come from one compatibility set, fix that before investigating anything else — it is the cause of most confusing behaviour.

## Common first-start failures

| What you see                                  | What it means                                                                                                                                                   |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `nxc_server_build is not set`                 | Fill it in. `nxc_core` refuses to start without it, deliberately                                                                                                |
| `mysql_connection_string is empty`            | Fill it in                                                                                                                                                      |
| Nothing at all from `nxc_core`                | It is not started, or `nxc_lib` is missing                                                                                                                      |
| `attempt to index a nil value (global 'Nxc')` | `nxc_lib` is not installed, or is older than the set                                                                                                            |
| `NXC_CORE_SIGNING_KEY_TOO_SHORT`              | You supplied `nxc_token_signing_key` and it is under 32 characters. It is refused rather than silently replaced. Remove the line unless you need it             |
| `NXC_CORE_SIGNING_KEY_UNAVAILABLE`            | A key could not be generated. The database is reachable but its random source did not return enough bytes — this is a database problem, not a configuration one |

## About the signing key

**You do not set one.** Nexus Core generates a key at every startup from the database's cryptographic random source, which is why the startup line reads:

```
[INFO] nxc_core startup.signing_key_ready  source=generated
```

`source=operator` means you supplied one. That is supported, and it is only needed if you run more than one server instance that must share sessions — a supplied key must be at least 32 characters.

The convar is **commented out** in the shipped `server.cfg`, deliberately. An absent convar and a blank one behave identically, but only a blank one can be silently overridden by a second blank `set` written below it on a redeploy — which is how a filled-in key was lost once already.

Generating a key at startup means **restarting invalidates live sessions and players reconnect**. That is intended: a session token that outlives the server which issued it is a token nobody can revoke.

See [When something goes wrong](/nexus-core-docs/running-your-server/troubleshooting.md) for anything not listed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nxcframework.net/nexus-core-docs/start-here/first-start.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.