Swarm options and log destinations

Every Docker Swarm setting an application can have beyond its size and command, which ones need a cluster of your own, and how to send logs to Loki, Elastic, Graylog or Splunk.

An application's size, copies, environment, command, health check and rollout have their own panels. Swarm options is everything else Docker Swarm can set on the service. Each one left empty keeps Docker's default, and clearing one puts that default back at the next deploy.

Set them in the console (application page, Swarm options), with isogrid apps options <app>, or in a stack file, where the usual compose keys are read.

What you can set

Area	Options	Compose keys
Scheduling	spread copies over a node label, most copies per machine, CPUs reserved per copy	`deploy.placement.preferences`, `max_replicas_per_node`, `deploy.resources.reservations.cpus`
Container	working directory, hostname, stop signal, init process, read-only filesystem, TTY, ulimits, process limit, extra groups, dropped capabilities	`working_dir`, `hostname`, `stop_signal`, `init`, `read_only`, `tty`, `ulimits`, `group_add`, `cap_drop`
Files	configuration files made from text (Swarm configs)	`configs` with an inline `content:`
Network	extra `/etc/hosts` lines, DNS servers, search domains and options, one address per copy (`dnsrr`)	`extra_hosts`, `dns`, `dns_search`, `dns_opt`, `deploy.endpoint_mode`
Logs	where the output goes	`logging.driver`, `logging.options`

Files are for configuration that is not secret. Secrets belong in a vault and reach the container as files or variables.

Options that need a cluster of your own

Some options reach the machine itself. They run only on a cluster that is yours: a private cluster granted to your organization alone, or one run by your Nomad agent. On a shared region they are refused, and the console says so.

added capabilities (cap_add) and kernel settings (sysctls)
the OOM score (oom_score_adj)
the machine's network (network_mode: host): the application then leaves its private network
directories of the machine (bind mounts)
ports published on the machines (ports with mode: host or mode: ingress)
node resources such as GPUs (generic_resources)
one copy on every machine (deploy.mode: global). Switching to or from it recreates the service, with a short interruption, and such an application cannot be scaled or autoscaled.
raising any limit but nofile, or setting one to unlimited

On a cluster run by the Nomad agent, the ones that give root on the machine (capabilities, sysctls, OOM score, host network, bind mounts) also need the agent's consent: set ISOGRID_NOMAD_ALLOW_PRIVILEGED=true on the agent. Without it, the agent refuses them, whatever ISOGrid asks.

Where logs go

By default the output stays on the machine, where the console and log search read it. You can send it somewhere else instead:

Docker's own drivers: syslog, gelf (Graylog, Logstash), fluentd, splunk, and, on your own cluster only, awslogs, gcplogs and journald, which use the machine's identity or journal.
Log plugins: Grafana Loki and Elastic. A plugin is installed on every machine of the region first: isogrid regions log-plugins <region> --install loki, or the button in the Swarm options panel. A plugin runs as root on each machine, so you install one on a cluster of your own; on a shared region ISOGrid's operators decide.

isogrid apps options shop --log-driver loki \
  --log-secret-opt loki-url=https://USER:TOKEN@logs.example.com/loki/api/v1/push --deploy

The console keeps showing the output whatever the destination: Docker keeps a local copy, sized like your retained logs. A destination that is slow or down never holds the application up: output is buffered (4 MB) and dropped past the buffer.

A token or password in a log option goes in the secret options: it is kept in the secret store and never shown again. On a cluster run by your Nomad agent, write it as {{secret:<reference>}} instead, so it stays in your Vault.

On a shared region a destination must be a public address: the machine sends the logs itself, and is not allowed to reach private networks on your behalf.

Searching JSON logs

When your application prints JSON lines, log search reads them as fields. The level is the logger's own (level, severity, pino's numbers), the message is its msg, and fields are filtered with @:

Query	Matches
`@status>=500`	a number compared (`>`, `>=`, `<`, `<=`)
`@http.method:GET`	equal, ignoring case; nested fields with dots
`@user.id:*`	the field is present
`@path:/api/*`	starts with
`@msg~timeout`	contains
`-@env:dev`	not that

They combine with words, phrases, level: and replica: as before.

Guide

What ISOGrid is — A cloud platform built in Algeria, for teams who want to ship without running servers.

Getting started — From an account to something running on the internet.

Your experience level — Three questions at first sign-in decide how your home page is laid out and how the assistant talks to you - and nothing else.

Deploying an application — From a repository to a running address, and what happens at each step.

How the build is detected — Which files count as a Dockerfile or a Compose file, how the port is found, and what happens when there are several candidates or none.

Compose and stack files — Deploying a Docker Compose or Swarm stack file - what is applied, what is not, and what applying it again does.

Swarm options and log destinations — Every Docker Swarm setting an application can have beyond its size and command, which ones need a cluster of your own, and how to send logs to Loki, Elastic, Graylog or Splunk.

Git repositories — Connecting GitHub or GitLab, deciding who in the organization may build from your repositories, and what happens when you leave.

Addresses and domains — The address every application gets, using your own name instead, and what breaks when DNS is wrong.

Connect your own network (VPN gateway) — Reach the services on a private network from your laptop, your office or another cloud, by alias, through a WireGuard gateway you open from the Networks page.

Databases — Ordering one, what each arrangement survives, and why replication is not a backup.

Vector search and AI with pgvector — Store embeddings in your PostgreSQL database and search them by meaning - switching pgvector on, a working example, indexes, and what to check first.

Object storage — Stores and buckets, what one node and several nodes survive, keys limited per bucket, and connecting over S3.

Volumes — Disk that outlives a copy. Where it comes from, what it survives, browsing it, and backing it up.

Managed services — Kafka, RabbitMQ, Redis and Keycloak - what you get, what each arrangement survives, and how an application connects.

Private clusters without lock-in — What runs on your machines is standard Docker Swarm or Kubernetes, and it keeps running if you leave.

Supabase — A complete backend on PostgreSQL in one deployment - what you get, which database to put behind it, and where your keys are.

Your own cluster with the Nomad agent — Deploy from the ISOGrid console on a Docker Swarm or Kubernetes you run yourself, without giving ISOGrid any access to your machines or your secrets.

Wazuh (security monitoring) — An open-source SIEM and XDR in one deployment - what you get, how to connect your machines to it, and what is yours to look after.

Roles, permission groups and access — The three layers that decide what each member may do, the groups every organization starts with, and the rules that stop anyone climbing.

The AI Studio sandbox — The workspace behind every Studio project - starting, pausing and restarting it, what happens when it is left unused, and how your files come back.

The DevOps Agent and your code — How the agent deploys repositories you already have, what it asks before acting, and when the code it cloned is deleted.

REST API — The address, how a script signs in, how the organization is chosen, what errors look like, and worked examples with curl.

Prices and billing — The subscription prices, why resource prices are set per region, what is paid ahead and what by the hour, what happens when credit runs out, and how to get an invoice.

When things go wrong — The failures you are most likely to meet, what each one actually means, and what to do.

Command line

Installing the CLI — One command on Linux, macOS or Windows, a checksum on every download, and how to update or remove it.

Command reference — Every command group, what it does, and where each one is explained in full.

Automating applications — Create, configure, deploy and remove applications from a terminal or a script, with every flag explained.

Deploying from CI/CD — Deploy on every push from GitHub Actions or GitLab CI/CD, with a narrow credential and a job that fails when the deployment does.

Repositories, groups and access — Decide who can build from a repository, manage permission groups and read who holds what, from the terminal.

Tutorials

Your first deployment — A repository to a working address, with the mistakes pointed out before you make them.

An application with a database — An API and a managed PostgreSQL, joined by a secret, running as two copies, with a backup you have restored once.

Deploy on every push — From a first deployment by hand to one on every push, from GitHub Actions or GitLab CI/CD, with a credential that cannot do more, and what happens when a release fails.

Policy

Availability and support — What the platform commits to, what it does not, and how to reach a person.

Acceptable use — What you may run, what you may not, and what happens if a line is crossed.

Privacy — What personal data ISOGrid keeps, why, who else sees it, how long it is kept, and how to delete your account.