# Services

Run a service of your own next to the application, on an image you build, reached by the application with a secret only the two hold.


Some applications need a program next to them that is not PHP: a model that recognises names in text, a converter, a search engine. A service runs it in a container of its own, in the same Scaleway project and region as the application.

## In brewless.yml

Name the service under the environment, with the directory that holds its Dockerfile:

```yaml brewless.yml
environments:
  production:
    services:
      gliner:
        build: services/gliner
        memory: 4096
        cpu: 2240
        timeout: 300
```

A service name has lowercase letters and digits, starts with a letter and has no dashes; `web`, `release` and `worker` are taken. Without sizes a service gets 1024 MB, 560 thousandths of a vCPU, a timeout of 60 seconds and at most one replica, and it sleeps when nobody calls it (`min: 0`). See [brewless.yml](/reference/brewless-yml) for the bounds.

## Putting it live

```bash
brewless service:push production gliner
```

This builds the Dockerfile with Docker on your own machine, for `linux/amd64`, and uploads the image straight into a private bucket of your Scaleway project. A job in that project pushes it into your project's own registry, and Brewless makes the container `gliner` next to the web container, or gives the one there the new image. The image is never public and never passes through Brewless. The same image is not pushed twice: its tag is the identifier Docker gave it.

The container listens on the port in the `PORT` variable (8080). Brewless gives it one more variable, `SERVICE_TOKEN`: a secret it makes once in your Secret Manager and never replaces. The service has to refuse every request that does not carry it.

> [!NOTE]
> Brewless does not build services in your project, as it does your application: a job there runs without privileges and cannot run a Dockerfile. That is why the image of a service is built where Docker is: on your machine.

## How the application reaches it

The next deploy gives the web, release and worker containers two variables per service: `GLINER_URL`, the address of the service's container, and `GLINER_TOKEN`, the same secret the service holds. Send the secret with every call, for example as `Authorization: Bearer <GLINER_TOKEN>`. The application calls the service directly; Brewless is not in between.

A deploy is refused while `brewless.yml` names a service that does not run yet: push it first. The variables go next to the environment's own variables, so a deploy with a service also needs those kept through Brewless (push them once with `brewless env:push`).

Changing the sizes of a service in `brewless.yml` takes effect at the next `brewless service:push`. Taking a service out of the file stops the application getting its variables at the next deploy; the container itself keeps running until you remove it in your Scaleway console.