Logs

Everything your containers write — the application, the web server, the database — is collected on the machine they run on. You do not have to configure anything for that to happen.

#Logging from your own code

A container has no syslog daemon. Drupal's core syslog module sends its lines to a socket nothing is listening on, so a site configured that way logs to nowhere at all.

Write files instead. Every application container has a directory at /var/log/app, and the same path is in the environment as VALLIC_LOG_DIR. Anything you write there is collected with the rest of your logs: kept on the machine, and forwarded if you have set up a destination.

For Drupal, the Monolog module with a rotating file handler:

// settings.php — or the monolog settings the module reads.
$settings['monolog.channel_handlers']['default'] = ['rotating_file'];
$settings['monolog.handlers']['rotating_file'] = [
  'type' => 'rotating_file',
  'path' => ($_ENV['VALLIC_LOG_DIR'] ?? '/var/log/app') . '/drupal.log',
  'max_files' => 7,
];

For Laravel, point the daily channel at the same directory — there is a worked example on the Laravel page, along with the reason it matters there in particular: Laravel's default log path is inside the release, so it starts again on every deploy.

You can read and clear the directory yourself from the environment shell — it is /var/log/app in there, like everywhere else in the stack.

There is a limit: a tenth of the storage your environment is assigned, between 100 MB and 20 GB. Past it we remove the oldest files first, and never the one being written.

It does not count towards the storage you are assigned. The room your logs take is ours to manage, not something subtracted from the disk you bought.

Set your logger to rotate and you will never meet the limit; if you need to keep more than that, forward a copy somewhere that keeps it.

#What is kept, and for how long

Seven days, on the machine. A container that has been restarted has not taken its history with it, and you do not need a third-party account to read it. Older than that is removed, because a busy site would otherwise fill the disk its own stack is running on.

If you need longer than a week, send a copy somewhere that keeps it — below.

#The access log

The web server in front of your site always writes an access log, because the platform counts requests and measures response times from it. By default it holds only what that counting needs — which site, which path, the status, how long it took, when. No visitor address, no query string, no user agent: nothing that is somebody's personal data. The full line, addresses and all, is written only when full access logging is switched on for the project, and never on a machine shared with other teams, because one customer cannot consent for another's visitors. Turning it on makes you the controller of that data.

#Sending a copy somewhere else

Two steps, because the credentials belong to your team rather than to one project.

1. Add the collector once, under your team's settings, in Integrations. Datadog, New Relic, Logz.io, Axiom, Grafana Loki, Splunk, an OpenTelemetry collector, a plain syslog endpoint, or an S3-compatible bucket to archive them in. You give it a name, whatever that service needs to identify your account, and the token. The token is encrypted and never shown again.
2. Choose it as the destination on the project's configuration page. Any project on the team can point at the same integration, and rotating the token in one place fixes all of them. Both steps take the Admin role or above.

Forwarding is not offered on the entry line of machines. The logs are still kept on the machine either way; a larger machine adds sending them somewhere of your own.

A plain syslog endpoint is still a destination. Host, port, protocol, no token. TCP unless the endpoint insists otherwise: UDP drops messages silently under exactly the load that produces the logs you want to read.

This is additive. It does not stop the machine keeping its own copy, and it does not replace anything — it is a second destination. Shipping is done by Vector on the machine.

#What is sent, and what is not

Only your project's containers. Never another customer's, and never the machine's own output — the machines are shared, and a log stream that carried your neighbours' traffic would be somebody else's data arriving in your account.

If the endpoint is unreachable, messages queue on disk and are delivered when it comes back rather than being dropped. The logs worth having off the machine are usually the ones produced while something was wrong, which is exactly when a destination is most likely down.

#Changes take effect on the next reconcile

Saving a destination sends it to every machine the project runs on, which picks it up within about a minute.

#Next

Backups covers the other thing that leaves the machine, Monitoring covers metrics and availability, and Shell access covers reading what is on the machine yourself.