Environments

An environment is a named set of variables stored as JSON. A workspace can hold any number of them; exactly one is active at a time. The active environment is recorded in the workspace’s personal state file so it survives restarts, and if that environment no longer exists Fetchpier falls back to the first available one.

Variables defined by an environment feed {{name}} placeholders, auth fields, and TLS passphrases. Pre-request scripts can read and write them — see Variables.

How an environment is named on disk

Each environment lives in its own folder, named after the environment in a filesystem-safe form: accented characters are transliterated to their base letter (Producción → produccion), everything else outside letters and digits becomes a hyphen, and very long names are shortened at a hyphen. That folder name is the environment’s public handle — it is what version control tracks and what a command-line run names — while the display name is kept exactly as you typed it.

Two environments may not land in the same folder: a name that collides with an existing one, or that contains no letter or digit at all, is rejected on the spot and you are asked to pick another. Fetchpier never invents a name on your behalf. A rejected name leaves the field open with the text as typed, so you correct it rather than retyping it.

Separately from both names, every environment carries a stable internal identifier that never changes. That is what makes renaming safe: renaming moves the folder and changes the label, but the environment it is stays the same, so the active selection, its cookie jar, and its machine-local values all follow it with nothing to re-point. Renaming an environment’s folder by hand outside the app is a legitimate way to rename it — Fetchpier reads what it finds, adopts the folder name as the display name, and never moves the files back.

Managing environments

The Environments panel lets you create, edit and switch environments. Clicking an environment in the list opens it for editing; right-clicking does the same and opens a menu with rename, duplicate and delete, so the menu never acts on an environment whose variables you cannot see:

• Rename edits the row in place, pre-filled with the current name. It moves the environment’s folder and relabels it; nothing else changes — the same environment stays selected and stays active, and its cookies and machine-local values move with it.
• Duplicate opens a new row below the source, pre-filled with the first free <name>-copy (then -copy-2, …). Nothing is written until the name is confirmed. The copy gets every variable of the source verbatim — plain, secret and “needs value” alike, so encrypted values keep working without ever being decrypted — but starts with an empty cookie jar and no local value overrides, since that state is personal to one machine and is not part of what is being shared.
• Delete asks for confirmation in a dialog that names the environment and states that its machine-local cookies and value overrides go with it and have no other copy. When the deleted environment was the selected one, the first remaining environment takes its place.

A search box sits above the list, with the order buttons to its right. The search matches anywhere in the environment’s name, ignoring case and accents (produccion finds Producción), and says so when nothing matches — the create field stays available, so a search that finds nothing is one keystroke away from creating what you were looking for. The order is by name, A → Z or Z → A; the panel opens on A → Z. Both are ways of looking at the list, not changes to it: nothing is written, no environment moves on disk, and both reset the next time the panel is opened. A row whose name is being edited stays visible even when the search stops matching it, so a rejected name and its error are never filtered away mid-correction.

Environments are listed alphabetically wherever you pick one. The environment dropdown is sorted by name, and so is the maintenance panel by default — the order the folders happen to sit in on disk is an accident, not a choice anyone made.

The panel is an editor, not a selector. Which environment is active is chosen only by you, through the environment dropdown. Selecting a row in the maintenance panel loads that environment’s variables for editing and nothing more — closing the panel never changes which environment the next request resolves against. The single exception is deleting the active environment: it no longer exists, so the first remaining one takes its place.

Within an environment, every variable appears in a single list whose rows you can reorder by dragging; the chosen order is meaningful and persists across reloads. An unshared variable — one holding a local value the shared environment file does not have — is the one exception: it sits at the end of the list and has no drag handle until it reaches the shared file, because there is nowhere to record its position until then.

HTTP settings

A small set of HTTP behaviours is controllable at two levels: a workspace default and a per-request override. Per-request overrides take precedence; otherwise the workspace default applies.

Setting	Meaning
httpVersion	auto (negotiate — HTTP/2 if both endpoints support it), http1, or http2.
verifySsl	Whether to verify the server’s TLS certificate. Defaults to true.
followRedirects	Whether 3xx responses are followed automatically.
maxRedirects	Cap on the number of redirects followed.
followAuthorizationOnRedirect	Whether to keep the Authorization header when a redirect crosses hosts. Defaults to false (header stripped).
encodeUrl	When on, query-parameter values are percent-encoded after {{variable}} resolution, so a resolved value cannot break the query; when off, resolved values are sent raw — an escape hatch where you take responsibility for the bytes.
disableCookieJar	Skip cookie attachment and capture for this request.

Workspace-level changes broadcast to every open window, so concurrent users of the same workspace see consistent behaviour.

In addition to the per-request-overridable settings above, the workspace settings panel exposes one workspace-wide policy:

Setting	Meaning
binaryFileLimits.warnBytes	File size threshold above which attaching a binary body triggers a confirmation prompt. Default 50 MB.
binaryFileLimits.blockBytes	File size threshold above which a binary attachment is rejected outright. Default 100 MB.

These two thresholds are deliberately not per-request: the limit is a property of what this workspace can carry — in particular what its Git remote will accept on push — not a property of individual requests.