Run the Stack

Starting the Server

Copy the config, this is in .gitignore so you do not have to worry about accidentally committing secrets. This will be done automatically if it doesn't already exist when starting the api server locally with the Taskfile.
```
cp ./config/config-dev.example.yaml ./config/.config.yaml
```
Update the configuration with whatever respective settings you desire; the defaults inside should allow you to run the server without a problem

[!TIP] When developing locally, unless you are specifically testing subscriptions and module enforcement, ensure the following settings are set to false:
 entConfig:
   modules:
     enabled: false

 subscription:
   enabled: false

Use the task commands to start the server

Run the core server in development mode with dependencies in docker
```
task run-dev
```
Run fully in docker
```
task docker:all:up
```
Run fully in docker, with a published image:
```
task docker:core:published
```
In a separate terminal, with the server running, you can create a verified test user by running:
```
task cli:user:all
```
Once this command has finished ^, you can login and perform actions as user mitb@theopenlane.io with password mattisthebest1234

CSRF Tokens

The server enforces CSRF protection on all mutating requests. Clients must include a valid token in the X-CSRF-Token header. Existing client code can create a client with the CSRF Token using the following function. This function will grab a valid CSRF token from the /livez endpoint and send it for subsequent requests.

 client.ClientWithCSRFToken(ctx, opts...)

You can also manually call InitCSRF on the client:

ctx := context.Background()
if err := client.InitCSRF(ctx); err != nil {
    // handle error
}

The CLI has been updated to call ClientWithCSRFToken automatically, but other custom clients will need to adopt one of the approaches.

[!NOTE] Because the CSRF middleware stores the token only in the client’s cookie and not on the server, restarting the core server (or core server running in Kubernetes pods) does not invalidate the token. When the middleware receives a request, it checks the token in the csrf_token cookie against the X-CSRF-Token header. If the cookie is already present, that same token is used — no new token is generated. The token cookie persists until it expires (default 24h), so clients will continue to send the same value even if the server has restarted.

Therefore, rolling restarts on Kubernetes will not force new tokens to be issued and should not cause requests to fail, provided the client retains its CSRF cookie.

Starting the Server​

CSRF Tokens​

Starting the Server

CSRF Tokens