Which Appium server flags would you pin on an unattended box running an allotment watering-rota suite?

seniorshould knowfreq 40%

answer

the startup line is box policy
pin what a default would decide
box facts in default capabilities
narrow grant, never blanket
check the flag against the schema

basics

~20 s

Pin the interface, port and base path; pin the box's own facts with default capabilities; decide one session at a time or many; and grant the narrowest scoped insecure feature the lane needs instead of relaxing security wholesale.

solid answer

~40 s

Treat the startup line as the box's contract. Pin --address, --port and --base-path explicitly so the URL never depends on a default. Put the facts true of the box into --default-capabilities — this box drives Android through UiAutomator2, that one drives Apple devices through XCUITest — and leave anything a run varies in the suite. Decide whether the box is one lane (--session-override, so an orphan session cannot block the next run) or several (leave it off). For privilege, grant exactly what the lane needs with a scoped --allow-insecure and keep --relaxed-security off: it is the blanket version and hands every installed driver everything. Finally, the line is not portable — building the Apple agent needs macOS and Xcode, while an Android lane's server is happy on Linux.

Treat the startup line as the box's contract. Pin `--address`, `--port` and `--base-path` explicitly so the URL never depends on a default. Put the facts true of the *box* into `--default-capabilities` — this box drives Android through UiAutomator2, that one drives Apple devices through XCUITest — and leave anything a run varies in the suite. Decide whether the box is one lane (`--session-override`, so an orphan session cannot block the next run) or several (leave it off). For privilege, grant exactly what the lane needs with a scoped `--allow-insecure` and keep `--relaxed-security` off: it is the blanket version and hands every installed driver everything. Finally, the line is not portable — building the Apple agent needs macOS and Xcode, while an Android lane's server is happy on Linux.

code

bash · 4 lines

bash

appium --address 127.0.0.1 --port 4726 --base-path /wd/hub \
  --default-capabilities '{"platformName":"Android","appium:automationName":"UiAutomator2"}' \
  --session-override \
  --allow-insecure=uiautomator2:adb_shell

go deeper

for a junior

Know that an Appium server is configured by the flags it starts with, and that an unattended box writes them down rather than relying on defaults it cannot see.

for a middle

Explain what each pinned flag decides — interface, port, prefix, default capabilities, session clobbering, privilege — and which of them a suite should never depend on being defaulted for it.

for a senior

Be ready to defend the split between box facts and suite facts, to justify a narrow scoped grant over relaxing security, and to say why the Android and Apple boxes need different lines.

for a principal

Own the startup line as policy: who may change it, how a change is reviewed, and how the fleet keeps one convention per lane so a suite moves between boxes without an edit.

The startup line is the box's contract

An unattended Appium box has no operator to answer questions at run time. Everything the server needs to decide has to be decided in the line that starts it, and the useful discipline is to pin anything a default would otherwise decide for you. Defaults move, boxes get rebuilt, and a suite that works because of a default is a suite that breaks on the day the default changes.

One guard rail before the list: the flags a server accepts are the ones declared in its own configuration schema. That sounds obvious, and it is the source of two real failures covered at the end.

Addressing: --address, --port, --base-path

Pin all three. --address (-a) chooses the interface to bind, --port (-p) the TCP port to listen on, --base-path (-pa) the prefix the whole WebDriver route table is mounted under. Written explicitly, the box's URL is a fact you can put in a runbook instead of a guess about which defaults this build shipped with. Binding loopback rather than a routable interface is also the cheapest thing you can do to stop an unattended server answering strangers.

Box facts belong in --default-capabilities

--default-capabilities (-dc) takes a JSON object of capabilities the server folds into every new session — passed inline or read from a file. The rule for what goes in it is ownership, not convenience:

In: things true of the box and only the box — which driver this box drives (appium:automationName of UiAutomator2 on an Android box, XCUITest on an Apple one) and which wired device it owns.
Out: anything a case or a run varies — the build under test, reset behaviour, per-run tuning. If two runs on this box must be able to differ in it, it cannot live in the box's startup line.

Every capability you move into -dc is one a suite reader can no longer see, so move only the ones nobody would have expected to find in the suite anyway.

One lane or many: --session-override

With --session-override, a new session first deletes the sessions the server already holds. On a box that runs one suite at a time that is orphan recovery for free: a run killed mid-suite leaves a session holding the device, and the next run clears it instead of failing. On a box that deliberately runs several sessions at once it is destructive, because each new session tears down its neighbours. Decide which kind of box this is and set the flag accordingly — never "just in case".

Privilege: grant narrow, not broad

Three flags sit here and they are not interchangeable:

--allow-insecure=<scope>:<feature> grants one feature to one driver, or to every driver with the * scope. Appium 3 requires the scope and refuses to start without it.
--relaxed-security is the blanket switch. It is the "this box is trusted" setting, not a synonym for a scoped grant.
--deny-insecure takes the same scoped shape and records what this box must not run.

For the watering-rota box: if the Android lane's fixture step needs a device shell, grant uiautomator2:adb_shell and nothing else. The Apple lane's XCUITest driver gains nothing from that value, which is the whole point of scoping it, and a box shared between teams stays as narrow as its narrowest lane needs.

The box is not portable

One startup line does not serve every host. The Android lane's server is content on a Linux machine. The Apple lane's is not: building the WebDriverAgent test agent uses Xcode, and Apple simulators run on macOS only, so that box is a Mac. Two boxes, two lines, and a written note of which lane lives where — otherwise the first person to copy the Android line onto the Apple machine loses an afternoon.

Flags that are not flags

Two traps produce a box that will not start at all:

A client library's flag enum is not the server's flag list. java-client still carries names from an older server line — --shell, --show-config, --async-trace, --enable-heapdump — and none of them is in the Appium 3 server schema. Read the schema, not the binding.
Not everything the CLI accepts is a server flag. --config is a CLI-level argument rather than one of the server's declared flags, so treating the two sets as one produces confident, wrong startup lines.

Appium also ships --allow-unknown-args, which is a strong hint that an unrecognised argument is otherwise a startup failure rather than something quietly skipped. On an unattended box that is what you want: fail at start, loudly, instead of an hour into a run.

A checklist for the watering-rota box

Interface, port and base path written explicitly.
-dc carrying the driver and the device this box owns, and nothing a run varies.
--session-override if and only if the box runs one session at a time.
The narrowest scoped --allow-insecure the lane needs, with --relaxed-security left off.
Every flag checked against the server's schema before it goes in.
The Android line and the Apple line kept as two files, because the hosts are not interchangeable.

## The startup line is the box's contract An unattended Appium box has no operator to answer questions at run time. Everything the server needs to decide has to be decided in the line that starts it, and the useful discipline is to pin anything a default would otherwise decide for you. Defaults move, boxes get rebuilt, and a suite that works because of a default is a suite that breaks on the day the default changes. One guard rail before the list: the flags a server accepts are the ones declared in its own configuration schema. That sounds obvious, and it is the source of two real failures covered at the end. ## Addressing: --address, --port, --base-path Pin all three. `--address` (`-a`) chooses the interface to bind, `--port` (`-p`) the TCP port to listen on, `--base-path` (`-pa`) the prefix the whole WebDriver route table is mounted under. Written explicitly, the box's URL is a fact you can put in a runbook instead of a guess about which defaults this build shipped with. Binding loopback rather than a routable interface is also the cheapest thing you can do to stop an unattended server answering strangers. ## Box facts belong in --default-capabilities `--default-capabilities` (`-dc`) takes a JSON object of capabilities the server folds into every new session — passed inline or read from a file. The rule for what goes in it is ownership, not convenience: - **In:** things true of the box and only the box — which driver this box drives (`appium:automationName` of `UiAutomator2` on an Android box, `XCUITest` on an Apple one) and which wired device it owns. - **Out:** anything a case or a run varies — the build under test, reset behaviour, per-run tuning. If two runs on this box must be able to differ in it, it cannot live in the box's startup line. Every capability you move into `-dc` is one a suite reader can no longer see, so move only the ones nobody would have expected to find in the suite anyway. ## One lane or many: --session-override With `--session-override`, a new session first deletes the sessions the server already holds. On a box that runs one suite at a time that is orphan recovery for free: a run killed mid-suite leaves a session holding the device, and the next run clears it instead of failing. On a box that deliberately runs several sessions at once it is destructive, because each new session tears down its neighbours. Decide which kind of box this is and set the flag accordingly — never "just in case". ## Privilege: grant narrow, not broad Three flags sit here and they are not interchangeable: - `--allow-insecure=<scope>:<feature>` grants one feature to one driver, or to every driver with the `*` scope. Appium 3 requires the scope and refuses to start without it. - `--relaxed-security` is the blanket switch. It is the "this box is trusted" setting, not a synonym for a scoped grant. - `--deny-insecure` takes the same scoped shape and records what this box must not run. For the watering-rota box: if the Android lane's fixture step needs a device shell, grant `uiautomator2:adb_shell` and nothing else. The Apple lane's XCUITest driver gains nothing from that value, which is the whole point of scoping it, and a box shared between teams stays as narrow as its narrowest lane needs. ## The box is not portable One startup line does not serve every host. The Android lane's server is content on a Linux machine. The Apple lane's is not: building the WebDriverAgent test agent uses Xcode, and Apple simulators run on macOS only, so that box is a Mac. Two boxes, two lines, and a written note of which lane lives where — otherwise the first person to copy the Android line onto the Apple machine loses an afternoon. ## Flags that are not flags Two traps produce a box that will not start at all: 1. **A client library's flag enum is not the server's flag list.** `java-client` still carries names from an older server line — `--shell`, `--show-config`, `--async-trace`, `--enable-heapdump` — and none of them is in the Appium 3 server schema. Read the schema, not the binding. 2. **Not everything the CLI accepts is a server flag.** `--config` is a CLI-level argument rather than one of the server's declared flags, so treating the two sets as one produces confident, wrong startup lines. Appium also ships `--allow-unknown-args`, which is a strong hint that an unrecognised argument is otherwise a startup failure rather than something quietly skipped. On an unattended box that is what you want: fail at start, loudly, instead of an hour into a run. ## A checklist for the watering-rota box 1. Interface, port and base path written explicitly. 2. `-dc` carrying the driver and the device this box owns, and nothing a run varies. 3. `--session-override` if and only if the box runs one session at a time. 4. The narrowest scoped `--allow-insecure` the lane needs, with `--relaxed-security` left off. 5. Every flag checked against the server's schema before it goes in. 6. The Android line and the Apple line kept as two files, because the hosts are not interchangeable.

Which capabilities belong in `--default-capabilities` and which must stay in the suite?
Anything true of the box and only the box: which driver it drives — `appium:automationName` of `UiAutomator2` on the Android box, `XCUITest` on the Apple one — and which device is wired to it. Anything a run varies, such as the build under test or reset behaviour, stays in the suite; otherwise two runs on the same box could never differ.
A teammate copies `--enable-heapdump` from a client library's flag enum and the server will not start. What do you tell them?
That enum is a museum piece from an older server line. Appium 3's server flags are the ones its own configuration schema declares, and `--enable-heapdump`, `--shell`, `--show-config` and `--async-trace` are not among them. Check the schema rather than the client binding before adding anything to a box's startup line.

saying these in an interview costs you the question

Copies flags from a client library enum the server no longer accepts
Starts with --relaxed-security because one command was refused
Puts suite-specific capabilities into --default-capabilities
Assumes one startup line serves the Android and the Apple box alike
Relies on the default port and base path being what a tutorial said
Sets --session-override on a box that runs several sessions

Which Appium server flags would you pin on an unattended box running an allotment watering-rota suite?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The startup line is the box's contract

Addressing: --address, --port, --base-path

Box facts belong in --default-capabilities

One lane or many: --session-override

Privilege: grant narrow, not broad

The box is not portable

Flags that are not flags

A checklist for the watering-rota box

▾common follow-ups2 questions

▾red flags6 flags

The startup line is the box's contract

Addressing: --address, --port, --base-path

Box facts belong in --default-capabilities

One lane or many: --session-override

Privilege: grant narrow, not broad

The box is not portable

Flags that are not flags

A checklist for the watering-rota box

answer

go deeper