sneak/pixa
1
0
Fork 0
Code Issues 12 Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Format the markdown with prettier in script/fmt and script/fmt-check (closes #100)
check / check (push) Failing after 3s
Details

Browse Source 
script/fmt and script/fmt-check run prettier 3.8.1 on the markdown after
gofmt, with the same yarn helper and arguments as the copies in
sneak/prompts. prettier is pinned in package.json and yarn.lock;
.prettierrc sets four-space tabs and proseWrap always, and
.prettierignore keeps prettier off REPO_POLICIES.md and vendor/. Plain
script/bootstrap installs Node and Yarn the way the one in sneak/prompts
does; with --cgo it does not, as the Dockerfile stages that pass it
format nothing. The HTML templates stay out: prettier cannot parse a Go
template action inside a tag. This commit also holds the reflow that
make fmt then produced (lines rewrapped, bullets as dashes, no word
changed), which the PR kept as a separate commit for review.

Model: opus-5-5
This commit was merged in pull request #219.
This commit is contained in:
clawbot
2026-10-05 04:24:45 +02:00
parent a941a80bf9
commit 01823d27db
10 changed files with 710 additions and 589 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+171 -175
View File
@@ -1,10 +1,9 @@
# pixa
pixa is a GPL-3.0-licensed Go web server by
[@sneak](https://sneak.berlin) that proxies images from upstream
sources, optionally resizing or transforming them, and serves the
results. Both source and transformed images are cached to disk so that
subsequent requests are served without origin fetches or additional
pixa is a GPL-3.0-licensed Go web server by [@sneak](https://sneak.berlin) that
proxies images from upstream sources, optionally resizing or transforming them,
and serves the results. Both source and transformed images are cached to disk so
that subsequent requests are served without origin fetches or additional
processing.
## Getting Started
@@ -27,12 +26,11 @@ make docker
docker run -p 8080:8080 -e PIXA_SIGNING_KEY="$(openssl rand -base64 32)" pixa:latest
```
A container takes its settings from environment variables (see
Configuration below for the list). Only `PIXA_SIGNING_KEY` is required; if
it is unset the container exits at startup naming the variable. Everything
else has a built-in default. A config file mounted at `/etc/pixa/config.yml`
is optional: it is read when present, and an environment variable wins over
the same setting in it.
A container takes its settings from environment variables (see Configuration
below for the list). Only `PIXA_SIGNING_KEY` is required; if it is unset the
container exits at startup naming the variable. Everything else has a built-in
default. A config file mounted at `/etc/pixa/config.yml` is optional: it is read
when present, and an environment variable wins over the same setting in it.
## Deployment
@@ -94,41 +92,40 @@ Outside Docker, pixa needs libvips (the image has 8.15) and libheif to run, as
it uses libvips through CGO; building it also needs their development files,
`pkg-config` and a C compiler. `script/bootstrap --cgo` installs all of these,
as the `Dockerfile` does where it compiles pixa. Plain `script/bootstrap`, which
`script/setup` and `script/cibuild` run, installs only git, make and Go: the
checks compile pixa in Docker, so the host needs none of the C libraries. Docker
itself must already be installed.
`script/setup` and `script/cibuild` run, installs git, make and Go, and Node,
Yarn and the prettier pinned in `yarn.lock` for formatting the markdown, but
none of the C libraries: the checks compile pixa in Docker. Docker itself must
already be installed.
## Running under upaas
What the [upaas](https://git.eeqj.de/sneak/upaas) app for pixa needs:
- **Port:** pixa listens on container port `8080`.
- **Volume:** container path `/var/lib/pixa`, where pixa keeps its
database and cache. Creating the host directory when it is missing is
upaas's job, tracked in https://git.eeqj.de/sneak/upaas/issues/235.
- **Volume:** container path `/var/lib/pixa`, where pixa keeps its database and
cache. Creating the host directory when it is missing is upaas's job, tracked
in https://git.eeqj.de/sneak/upaas/issues/235.
- **Environment variables:**
- `PIXA_SIGNING_KEY` (required): secret for signed and encrypted URLs
and login, 32+ characters, for example from
`openssl rand -base64 32`
- `PIXA_SIGNING_KEY` (required): secret for signed and encrypted URLs and
login, 32+ characters, for example from `openssl rand -base64 32`
- `PIXA_ALLOWLIST_HOSTS`: upstream hosts served without a signature,
comma-separated
- `PIXA_CACHE_MAX_BYTES`: disk cache limit in bytes; `0` disables it;
default 75% of (free space + what the cache holds)
- the rest are in the table under Configuration below
- **Health check:** the image's `HEALTHCHECK` requests
`/.well-known/healthcheck.json`. upaas reads the container's health 60
seconds after a deploy and marks the deploy failed unless it is
`healthy`. The probe uses the port from `PORT` (default `8080`), so a
port changed only in a mounted config file is not seen by it: change
the port with `PORT`.
`/.well-known/healthcheck.json`. upaas reads the container's health 60 seconds
after a deploy and marks the deploy failed unless it is `healthy`. The probe
uses the port from `PORT` (default `8080`), so a port changed only in a
mounted config file is not seen by it: change the port with `PORT`.
## Rationale
Image-heavy web applications need a fast, caching reverse proxy that
can resize and transcode images on the fly. pixa fills that role as a
single, self-contained binary with no external runtime dependencies
beyond libvips. It supports HMAC-SHA256 signed URLs with expiration to
prevent abuse, and allowlisted source hosts for open access.
Image-heavy web applications need a fast, caching reverse proxy that can resize
and transcode images on the fly. pixa fills that role as a single,
self-contained binary with no external runtime dependencies beyond libvips. It
supports HMAC-SHA256 signed URLs with expiration to prevent abuse, and
allowlisted source hosts for open access.
## Design
@@ -137,8 +134,8 @@ prevent abuse, and allowlisted source hosts for open access.
- **Source content**:
`<state_dir>/cache/sources/<ab>/<cd>/<sha256 of source content>`
- **Source metadata**:
`<state_dir>/cache/metadata/<hostname>/<sha256 of path and query>.json`
(host, path and query, content hash, upstream status and headers, fetch time)
`<state_dir>/cache/metadata/<hostname>/<sha256 of path and query>.json` (host,
path and query, content hash, upstream status and headers, fetch time)
- **Database**: `<state_dir>/state.sqlite3` (SQLite)
- **Transformed images**:
`<state_dir>/cache/variants/<ab>/<cd>/<sha256 of host, path, query, size, format, quality and fit>`,
@@ -147,8 +144,8 @@ prevent abuse, and allowlisted source hosts for open access.
`<ab>` and `<cd>` are the first and second pairs of characters of the file's
name.
Multiple source paths may reference the same content blob; the
database tracks references rather than using filesystem refcounting.
Multiple source paths may reference the same content blob; the database tracks
references rather than using filesystem refcounting.
pixa's target is 1-5k r/s, which has not been measured at that rate (see Load
Test). Toward it, pixa keeps in memory the content types of the 10,000
@@ -163,8 +160,8 @@ answers any method as it answers `GET`. A browser's CORS preflight request
(`OPTIONS` with `Origin` and `Access-Control-Request-Method` headers) to any
path under `/v1/` answers 200, in maintenance mode too.
- `GET /` — the login page, or the URL generator page with a login session
(see Encrypted URLs). Needs: nothing. Answers: 200.
- `GET /` — the login page, or the URL generator page with a login session (see
Encrypted URLs). Needs: nothing. Answers: 200.
- `POST /` — log in with the signing key typed into the login page. Needs: the
login page's form (below). Answers: 303 to `/` with a login session cookie
that lasts 30 days for the right key; 200 with the login page and an error for
@@ -197,11 +194,10 @@ path under `/v1/` answers 200, in maintenance mode too.
- `GET /robots.txt` — asks every crawler to stay away (`Disallow: /`). Needs:
nothing. Answers: 200.
- `GET /.well-known/healthcheck.json` — JSON with `status` (`ok`), `now`,
`uptime_seconds`, `uptime_human`, `version`, `appname` and
`maintenance_mode`. Needs: nothing. Answers: 200, always.
- `GET /static/<file>` — the stylesheet and script the login and generator
pages load. Needs: nothing. Answers: 200, or 404 for a file that does not
exist.
`uptime_seconds`, `uptime_human`, `version`, `appname` and `maintenance_mode`.
Needs: nothing. Answers: 200, always.
- `GET /static/<file>` — the stylesheet and script the login and generator pages
load. Needs: nothing. Answers: 200, or 404 for a file that does not exist.
- `GET /metrics` — Prometheus metrics (see Architecture). Needs: HTTP basic
authentication with `metrics.username` and `metrics.password`. Answers: 200;
401 without them; 404 when they are not set, as the route then does not exist.
@@ -225,9 +221,9 @@ HTTP is for development on the browser's own machine: the login session cookie
is always marked `Secure`, and over plain HTTP a browser keeps such a cookie
only for its own machine (`localhost`), if at all. A form is also refused with
403 when the page's host is not the `Host` header pixa receives, so a reverse
proxy in front of pixa must pass that header on unchanged. A form body over
1 MiB is refused with 413. The image routes answer the errors listed for them
with JSON holding `error`, `status` and `timestamp`.
proxy in front of pixa must pass that header on unchanged. A form body over 1
MiB is refused with 413. The image routes answer the errors listed for them with
JSON holding `error`, `status` and `timestamp`.
An image URL has this form:
@@ -239,8 +235,8 @@ Images are only fetched from origins using TLS with valid certificates, unless
`allow_http` is set: then pixa fetches every image over plain HTTP, which is for
testing only.
A request whose query string cannot be decoded, or gives any parameter more
than once, is refused with 400.
A request whose query string cannot be decoded, or gives any parameter more than
once, is refused with 400.
- `<format>`: one of `orig` (or `original`), `jpeg` (or `jpg`), `png`, `webp`,
`avif`, `gif`
@@ -248,39 +244,37 @@ than once, is refused with 400.
- `sig` and `exp`: the signature and its expiry, needed unless the host is
allowlisted (see Signature Specification)
- `q` and `fit`: the output quality and how the image is fitted to `<size>`,
both optional (values under Signature Specification). Both are part of what
is cached, so each value of either is a separate cached image.
both optional (values under Signature Specification). Both are part of what is
cached, so each value of either is a separate cached image.
An image is served with `Cache-Control: public, max-age=<seconds>, immutable`.
When the URL has an expiry (an `exp`, or the TTL of an encrypted URL),
`max-age` is the whole seconds left until then, at most one year, so no browser
or proxy cache keeps the image after pixa would refuse the URL. A URL with no
expiry gets one year. `immutable` only stops a client revalidating while its
copy is fresh.
When the URL has an expiry (an `exp`, or the TTL of an encrypted URL), `max-age`
is the whole seconds left until then, at most one year, so no browser or proxy
cache keeps the image after pixa would refuse the URL. A URL with no expiry gets
one year. `immutable` only stops a client revalidating while its copy is fresh.
When several requests for the same image, size, format, quality and fit miss
the cache at once, they share one upstream fetch (or one read of the cached
source) and one transcode: the first request does the work, and the others wait
for its image or its error, holding no upstream connection or processing slot
of their own. A waiting request stops waiting when its own client goes away.
The work goes on for the others even if the first request's client goes away,
until that request's `downstream_timeout` ends. The shared fetch sends the first
request's ID upstream, and the lines logged for the fetch and the transcode
carry that ID.
When several requests for the same image, size, format, quality and fit miss the
cache at once, they share one upstream fetch (or one read of the cached source)
and one transcode: the first request does the work, and the others wait for its
image or its error, holding no upstream connection or processing slot of their
own. A waiting request stops waiting when its own client goes away. The work
goes on for the others even if the first request's client goes away, until that
request's `downstream_timeout` ends. The shared fetch sends the first request's
ID upstream, and the lines logged for the fetch and the transcode carry that ID.
The login form (`POST /`) is limited to 5 attempts per minute per client
address, counting an IPv6 client by its /64; an attempt over the limit is
refused with 429 and a `Retry-After` header. Behind a reverse proxy the client
address comes from `X-Forwarded-For` only when the address pixa sees for
requests that come through the proxy is in `trusted_proxies`; otherwise all
users behind the proxy are counted as one client. That address is not always
the proxy's own: a proxy on the Docker host that connects to pixa over
`127.0.0.1` is seen as the gateway of the container's Docker network, such as
`172.17.0.1` on the default bridge, and one that connects through another of the
host's addresses is seen with that address. To be sure, read it as `remoteIP` in
pixa's request log while it is not in `trusted_proxies` (see `trusted_proxies`
under Configuration). With the default `trusted_proxies` (the RFC 1918 ranges),
a client with a private address can choose the address it is counted by through
users behind the proxy are counted as one client. That address is not always the
proxy's own: a proxy on the Docker host that connects to pixa over `127.0.0.1`
is seen as the gateway of the container's Docker network, such as `172.17.0.1`
on the default bridge, and one that connects through another of the host's
addresses is seen with that address. To be sure, read it as `remoteIP` in pixa's
request log while it is not in `trusted_proxies` (see `trusted_proxies` under
Configuration). With the default `trusted_proxies` (the RFC 1918 ranges), a
client with a private address can choose the address it is counted by through
its own `X-Forwarded-For`, whether it connects directly or through the proxy,
because its own address is trusted too. Setting `trusted_proxies` to only the
address pixa sees for requests that come through the proxy closes this.
@@ -305,18 +299,18 @@ nor change what it asks for.
with `http` instead while `debug` is on. The name after the token is ignored
and only gives the URL a file extension, `jpg` for `orig`.
The token holds the source's host, path and query and the size, format,
quality, fit and expiry, encrypted with a key derived from `signing_key`. The
source URL's scheme is not kept: the image is fetched like any other (see
Routes), and the blocked networks still apply.
The token holds the source's host, path and query and the size, format, quality,
fit and expiry, encrypted with a key derived from `signing_key`. The source
URL's scheme is not kept: the image is fetched like any other (see Routes), and
the blocked networks still apply.
How long the URL lasts is chosen on the page, from 1 minute to 1 year, or
never. The expiry is fixed in the token when the URL is made and cannot be
changed or revoked afterwards. Until then the image is served with a `max-age`
that ends at the expiry (see Routes); after it the URL answers 410
`URL has expired`. A URL made to last forever stops working only when
`signing_key` changes: changing it makes every encrypted URL already handed out
answer 400, and ends every login session.
How long the URL lasts is chosen on the page, from 1 minute to 1 year, or never.
The expiry is fixed in the token when the URL is made and cannot be changed or
revoked afterwards. Until then the image is served with a `max-age` that ends at
the expiry (see Routes); after it the URL answers 410 `URL has expired`. A URL
made to last forever stops working only when `signing_key` changes: changing it
makes every encrypted URL already handed out answer 400, and ends every login
session.
### Image Metadata
@@ -335,16 +329,15 @@ turned off.
### Source Hosts
Source hosts may be allowlisted in the configuration. Non-allowlisted
hosts require an HMAC-SHA256 signature.
Source hosts may be allowlisted in the configuration. Non-allowlisted hosts
require an HMAC-SHA256 signature.
#### Signature Specification
Signatures use HMAC-SHA256 and include an expiration timestamp to
prevent replay attacks. Signatures are **exact match only**: every
component (host, path, query, dimensions, format, expiration, quality,
fit) must match exactly what was signed. No suffix matching, wildcard
matching, or partial matching is supported.
Signatures use HMAC-SHA256 and include an expiration timestamp to prevent replay
attacks. Signatures are **exact match only**: every component (host, path,
query, dimensions, format, expiration, quality, fit) must match exactly what was
signed. No suffix matching, wildcard matching, or partial matching is supported.
**Signed data format** (colon-separated):
@@ -361,24 +354,24 @@ Where:
- `height` — requested height in pixels, `0` for original
- `format` — output format, one of those listed under Routes, with `original`
signed as `orig` and `jpg` as `jpeg`
- `expiration` — the URL's `exp` query parameter, the Unix timestamp when
the signature expires; a request whose `exp` is not a whole number, an
empty `exp=` included, is refused with 400
- `quality` — the URL's `q` query parameter, a whole number from 1 to 100,
or `85` when the URL has no `q`; a request whose `q` is anything else is
refused with 400
- `expiration` — the URL's `exp` query parameter, the Unix timestamp when the
signature expires; a request whose `exp` is not a whole number, an empty
`exp=` included, is refused with 400
- `quality` — the URL's `q` query parameter, a whole number from 1 to 100, or
`85` when the URL has no `q`; a request whose `q` is anything else is refused
with 400
- `fit` — the URL's `fit` query parameter (cover, contain, fill, inside,
outside), or `cover` when the URL has no `fit`; a request whose `fit` is
anything else, an empty `fit=` included, is refused with 400
The URL's `sig` is the HMAC-SHA256 result in base64url (the URL-safe alphabet
of RFC 4648) with the trailing `=` padding kept, 44 characters in all. pixa
The URL's `sig` is the HMAC-SHA256 result in base64url (the URL-safe alphabet of
RFC 4648) with the trailing `=` padding kept, 44 characters in all. pixa
compares it exactly, so a signature encoded without padding, as Node's
`base64url` and Go's `base64.RawURLEncoding` do, is refused with 401.
**Example:** with the signing key `example-signing-key-for-documentation`,
resize `https://cdn.example.com/photos/cat.jpg` to 800x600 WebP with
expiration 1704067200, default quality and fit:
resize `https://cdn.example.com/photos/cat.jpg` to 800x600 WebP with expiration
1704067200, default quality and fit:
1. Build input:
`cdn.example.com:/photos/cat.jpg::800:600:webp:1704067200:85:cover`
@@ -406,29 +399,29 @@ or a `*.` wildcard, aborts startup.
### Configuration
Every setting can be given as an environment variable, in a YAML config
file (`--config`), or both. A variable present in the environment wins over
the file, even when it is empty, and the file wins over the built-in
default. The one exception is a variable named in the file's `env:` section:
it is set while the file loads, so it overrides both the environment the
process was started with and the file's own key. A variable's value is
parsed as the same text in the file would be. The three lists take
comma-separated entries, with the spaces around each trimmed; an empty
variable is an empty list. A value that does not parse or is invalid aborts
startup, naming the variable. A variable whose name starts with `PIXA_` but
is not in the table below, such as a misspelled one or `PIXA_PORT`, aborts
startup naming it, as an unknown config key does. The one other accepted
name is `PIXA_CONFIG_PATH`, the config file's path (like `--config`). The
variables set by the file's `env:` section are checked the same way.
Every setting can be given as an environment variable, in a YAML config file
(`--config`), or both. A variable present in the environment wins over the file,
even when it is empty, and the file wins over the built-in default. The one
exception is a variable named in the file's `env:` section: it is set while the
file loads, so it overrides both the environment the process was started with
and the file's own key. A variable's value is parsed as the same text in the
file would be. The three lists take comma-separated entries, with the spaces
around each trimmed; an empty variable is an empty list. A value that does not
parse or is invalid aborts startup, naming the variable. A variable whose name
starts with `PIXA_` but is not in the table below, such as a misspelled one or
`PIXA_PORT`, aborts startup naming it, as an unknown config key does. The one
other accepted name is `PIXA_CONFIG_PATH`, the config file's path (like
`--config`). The variables set by the file's `env:` section are checked the same
way.
pixa reads at most one config file: the one given with `--config` (or `-c`),
otherwise the one `PIXA_CONFIG_PATH` names, otherwise the first of these that
pixa finds: `/etc/pixa/config.yml`, `/etc/pixa/config.yaml`,
`~/.config/pixa/config.yml`, `~/.config/pixa/config.yaml`, then `config.yml`
and `config.yaml` in the working directory. A named file that does not exist,
cannot be read or does not parse aborts startup. Of the files pixa looks for on
its own, only one that does not exist is passed over, without a message. One
that pixa cannot read or parse aborts startup, naming the file. So does one in a
`~/.config/pixa/config.yml`, `~/.config/pixa/config.yaml`, then `config.yml` and
`config.yaml` in the working directory. A named file that does not exist, cannot
be read or does not parse aborts startup. Of the files pixa looks for on its
own, only one that does not exist is passed over, without a message. One that
pixa cannot read or parse aborts startup, naming the file. So does one in a
directory pixa may not enter, whether or not it is there, since pixa cannot
tell. With no file, pixa uses the environment and the defaults.
@@ -463,11 +456,11 @@ Key settings in more detail:
of the image routes, `/v1/image/` and `/v1/e/`, sent as the CORS
`Access-Control-Allow-Origin` header; no other route sends it. `*`, the
default, is any site; otherwise one `http` or `https` origin such as
`https://example.com`, whose host is a lowercase host name (letters,
digits, hyphens and dots, with a letter in its last part) or an IP address
(IPv6 in brackets, in its shortest form), with an optional port 1-65535
that has no leading zero and is not the scheme's default. Any other value,
including another scheme such as a browser extension's, aborts startup
`https://example.com`, whose host is a lowercase host name (letters, digits,
hyphens and dots, with a letter in its last part) or an IP address (IPv6 in
brackets, in its shortest form), with an optional port 1-65535 that has no
leading zero and is not the scheme's default. Any other value, including
another scheme such as a browser extension's, aborts startup
- `allowlist_hosts` — list of allowed upstream hosts
- `referer_blocklist` — list of hosts whose pages may not show pixa's images, to
stop other sites hotlinking them. Entries are written and matched as for
@@ -476,40 +469,37 @@ Key settings in more detail:
`/v1/e/` whose `Referer` header names a listed host is refused with 403 before
its signature or token is checked and before the cache or the upstream host is
used, so it fetches nothing, and it is refused even when the image is cached.
A request with no `Referer`, or one that does not parse as a URL
with a host, is served, as many clients send none. So this is easily got
around: a site whose pages send no `Referer` (for example with
A request with no `Referer`, or one that does not parse as a URL with a host,
is served, as many clients send none. So this is easily got around: a site
whose pages send no `Referer` (for example with
`Referrer-Policy: no-referrer`) is not stopped. It does not apply to the login
and generator pages. Default: empty
- `blocked_networks` — list of CIDR ranges to refuse for SSRF protection,
added to the always-enforced built-in ranges (loopback, private,
link-local, CGNAT, benchmark, NAT64, and the like); an invalid CIDR
aborts startup
- `trusted_proxies` — list of CIDR ranges of the reverse proxies in front
of pixa. `X-Forwarded-For` is believed only when the direct peer falls
inside one of these ranges; the logged and login-recorded client
address is then the rightmost forwarded entry that is not itself a
trusted proxy. Otherwise the direct peer address is used and the header
is ignored, so a client connecting directly from an address outside
these ranges cannot spoof its address.
An omitted key defaults to the RFC 1918 private ranges (`10.0.0.0/8`,
`172.16.0.0/12`, `192.168.0.0/16`), since pixa is deployed behind a
proxy on a private network; an explicitly empty list (`[]`) trusts no
one, and an explicit list replaces the default. An invalid CIDR aborts
startup. Set this to the address pixa sees for requests that come through
your proxy, such as `172.17.0.1/32`, when the defaults do not cover it, or
to trust nothing else (see the login limit under Routes). For a proxy on
the Docker host that connects to pixa over `127.0.0.1`, that address is the
gateway of the container's Docker network (`172.17.0.1` on the default
bridge), not the proxy's own address; a proxy that connects through another of
the host's addresses is seen with that address. To be sure which address it
is, set this to `[]` (or `PIXA_TRUSTED_PROXIES` to empty), send a request
through the proxy, and read `remoteIP` in pixa's request log line for it
- `upstream_fetch_timeout` — time allowed for one fetch from an upstream
host, as a duration such as `30s` (the default) or `2m`
- `upstream_max_response_size` — largest upstream response accepted, in
bytes; default `52428800` (50 MiB). It also limits the image data pixa
decodes
- `blocked_networks` — list of CIDR ranges to refuse for SSRF protection, added
to the always-enforced built-in ranges (loopback, private, link-local, CGNAT,
benchmark, NAT64, and the like); an invalid CIDR aborts startup
- `trusted_proxies` — list of CIDR ranges of the reverse proxies in front of
pixa. `X-Forwarded-For` is believed only when the direct peer falls inside one
of these ranges; the logged and login-recorded client address is then the
rightmost forwarded entry that is not itself a trusted proxy. Otherwise the
direct peer address is used and the header is ignored, so a client connecting
directly from an address outside these ranges cannot spoof its address. An
omitted key defaults to the RFC 1918 private ranges (`10.0.0.0/8`,
`172.16.0.0/12`, `192.168.0.0/16`), since pixa is deployed behind a proxy on a
private network; an explicitly empty list (`[]`) trusts no one, and an
explicit list replaces the default. An invalid CIDR aborts startup. Set this
to the address pixa sees for requests that come through your proxy, such as
`172.17.0.1/32`, when the defaults do not cover it, or to trust nothing else
(see the login limit under Routes). For a proxy on the Docker host that
connects to pixa over `127.0.0.1`, that address is the gateway of the
container's Docker network (`172.17.0.1` on the default bridge), not the
proxy's own address; a proxy that connects through another of the host's
addresses is seen with that address. To be sure which address it is, set this
to `[]` (or `PIXA_TRUSTED_PROXIES` to empty), send a request through the
proxy, and read `remoteIP` in pixa's request log line for it
- `upstream_fetch_timeout` — time allowed for one fetch from an upstream host,
as a duration such as `30s` (the default) or `2m`
- `upstream_max_response_size` — largest upstream response accepted, in bytes;
default `52428800` (50 MiB). It also limits the image data pixa decodes
- `downstream_timeout` — time allowed for answering one client request, as a
duration; default `60s`. The upstream fetch counts toward it, and so do the
waits for an upstream connection and for a processing slot (up to 10 seconds
@@ -521,11 +511,11 @@ Key settings in more detail:
so a write that finds another in progress waits up to five seconds for it
instead of failing. WAL mode comes only from the URL: keep
`_pragma=journal_mode(WAL)` in one you set
- `cache_max_bytes` — disk cache size limit in bytes; `0` disables the
disk cache entirely; omitted defaults to 75% of the sum of the free space on
the filesystem containing `<state_dir>/cache/` and the bytes of source and
transformed images the cache already holds, worked out at startup (minimum
500 MiB)
- `cache_max_bytes` — disk cache size limit in bytes; `0` disables the disk
cache entirely; omitted defaults to 75% of the sum of the free space on the
filesystem containing `<state_dir>/cache/` and the bytes of source and
transformed images the cache already holds, worked out at startup (minimum 500
MiB)
- `upstream_connections` — the most connections to upstream hosts at once, all
hosts together, on top of `upstream_connections_per_host`; default `64`. A
fetch holds its connection until its image has been processed. A fetch that
@@ -540,10 +530,10 @@ Key settings in more detail:
- `maintenance_mode` — while `true`, the image routes (`/v1/image/` and
`/v1/e/`) answer every request for an image with 503, a `Retry-After` header
and a JSON error body. The health check (`/.well-known/healthcheck.json`)
still answers 200 and reports `"maintenance_mode": true`. It stays 200
because the image's Docker `HEALTHCHECK` requests it: a 503 there would make
the container unhealthy, and upaas marks a deploy failed when its container
is unhealthy. The login and URL generator pages and `/metrics` keep working
still answers 200 and reports `"maintenance_mode": true`. It stays 200 because
the image's Docker `HEALTHCHECK` requests it: a 503 there would make the
container unhealthy, and upaas marks a deploy failed when its container is
unhealthy. The login and URL generator pages and `/metrics` keep working
See `configs/config.example.yml` for all options with defaults.
@@ -565,21 +555,23 @@ See `configs/config.example.yml` for all options with defaults.
This repository adheres to the
[Scripts to Rule Them All](https://github.com/github/scripts-to-rule-them-all)
standard: normalized scripts in `script/` are the entrypoints for the
development workflow, and the Makefile targets are thin shims that call
them. We provide:
development workflow, and the Makefile targets are thin shims that call them. We
provide:
- `script/bootstrap` — install git, make and Go and download the Go modules
(idempotent); with `--cgo`, also the C compiler and the libvips and libheif
libraries that compiling pixa needs
- `script/setup` — make a fresh clone ready for development
(bootstrap, then install-precommit)
- `script/bootstrap` — install git, make, Go, Node, Yarn and prettier and
download the Go modules (idempotent); with `--cgo`, the C compiler and the
libvips and libheif libraries that compiling pixa needs instead of Node, Yarn
and prettier
- `script/setup` — make a fresh clone ready for development (bootstrap, then
install-precommit)
- `script/projectname` — output the project name ("pixa")
- `script/test` — run the test suite: build the `test` phase of the
`Dockerfile`, tagged `pixa-test`
- `script/lint` — run golangci-lint: build the `lint` phase of the `Dockerfile`,
tagged `pixa-lint`; the linter never runs on the host
- `script/fmt` — format all code (writes)
- `script/fmt-check` — check formatting (read-only), on the host
- `script/fmt` — format the Go code with gofmt and the markdown with prettier
(writes)
- `script/fmt-check` — check the same formatting (read-only), on the host
- `script/check` — run test, lint, and fmt-check
- `script/docker` — build the Docker image tagged via `script/projectname`, with
the version from `git describe`; the image's build stage depends on the `lint`
@@ -591,14 +583,18 @@ them. We provide:
then `script/check`, then build the image as `script/docker` does
- `script/precommit` — pre-commit checks (`go mod tidy` guard, then
`script/check`)
- `script/install-precommit` — install the git pre-commit hook that
runs `script/precommit`
- `script/install-precommit` — install the git pre-commit hook that runs
`script/precommit`
Every `docker build` in these scripts passes `--no-cache`, so the lint and test
phases run on every build instead of coming from the build cache.
`script/check`, `script/cibuild`, `script/docker`, `script/lint`, `script/test`,
`script/setup` and `script/install-precommit` are the standard copies from
`sneak/prompts`, kept identical to them.
`sneak/prompts`, kept identical to them. `script/fmt` and `script/fmt-check` are
the standard copies with pixa's `gofmt` step kept before prettier. prettier
formats the markdown only: not the HTML templates, as it cannot parse a Go
template action inside a tag, and not `REPO_POLICIES.md` (see
`.prettierignore`), a copy of the one in `sneak/prompts`.
## Load Test