Copy files in and out

Get a log or config file off a shell-less container, or push a patched file back in, over Pebble's files API.

Because the workload rock often has no shell, you can't scp out of it the way you might a machine. borescope moves files over Pebble's files API instead, with two commands that cross the boundary between the container and your local host.

Pull a file out

pull <remote> <local> copies a file from the container to your local filesystem:

pebble:/# pull /var/log/myapp/error.log ./error.log
Pulled /var/log/myapp/error.log -> ./error.log

The remote path is resolved relative to your current directory in the session, so this works too:

pebble:/# cd /var/log/myapp
pebble:/var/log/myapp# pull error.log ~/error.log

Push a file in

push <local> <remote> copies a local file into the container:

pebble:/# push ./fixed-config.yaml /etc/myapp/config.yaml
Pushed ./fixed-config.yaml -> /etc/myapp/config.yaml

push creates any missing parent directories on the remote side, so you don't need to mkdir first.

Pushing a file changes the running container. Pebble won't restart a service for you; use restart afterwards if the workload needs to re-read the file.

pull/push vs cat/cp

borescope has a few overlapping ways to move bytes; pick by intent:

pull/push always cross the host/container boundary; cp, mv, cat, head, and tail operate inside the container.

What works, what doesn't

• Single files. pull and push move one file at a time. Loop in a script for several, or exec tar in the container to bundle a tree first.
• Binary-safe. Files are transferred as raw bytes, so binaries and archives survive the round trip intact.
• Permissions follow Pebble. A push writes with Pebble's defaults; the workload must have permission to read the destination path.
• No globbing. Paths are literal. pull /var/log/*.log won't expand; use find to locate files, then pull them by name.