apify-cli 1.10.1-runtime.1 → 1.10.1-runtime.3

package/dist/actor.js

@@ -1,3 +1,3 @@
 #!/usr/bin/env node
-import{i as e,r as t,t as n}from"./_register-ocjWT2_T.js";t(`Actor`);for(let e of n)e.registerCommand(`actor`);await e(`actor`);export{};
+import{i as e,r as t,t as n}from"./_register-CN8ALErT.js";t(`Actor`);for(let e of n)e.registerCommand(`actor`);await e(`actor`);export{};
 //# sourceMappingURL=actor.js.map

package/dist/apify.js

@@ -1,3 +1,3 @@
 #!/usr/bin/env node
-import{i as e,n as t,r as n}from"./_register-ocjWT2_T.js";n(`Apify`);for(let e of t)e.registerCommand(`apify`);await e(`apify`);export{};
+import{i as e,n as t,r as n}from"./_register-CN8ALErT.js";n(`Apify`);for(let e of t)e.registerCommand(`apify`);await e(`apify`);export{};
 //# sourceMappingURL=apify.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "apify-cli",
-  "version": "1.10.1-runtime.1",
+  "version": "1.10.1-runtime.3",
   "description": "Apify command-line interface (CLI) helps you manage the Apify cloud platform and develop, build, and deploy Apify Actors.",
   "exports": "./dist/index.js",
   "type": "module",

package/skills/apify/SKILL.md

@@ -87,6 +87,67 @@ apify key-value-stores set-value <storeId> <key> <value>
 apify key-value-stores keys <storeId> --json
 ```
 
+## Local Actor runtime
+
+`apify runtime` runs a self-contained local Apify platform as a container on Docker or Podman. Use it to develop and test Actors against a platform-compatible API without touching the user's cloud account. It ships on the `runtime` npm dist-tag, not on `latest`.
+
+**Prerequisite: Docker or Podman.** One of them must be installed and running before any `apify runtime` command works; the CLI does not install either. It uses the first engine found on PATH (Docker before Podman); `APIFY_CONTAINER_ENGINE=podman` forces Podman.
+
+With Podman, the API socket must be served: check with `podman info --format '{{.Host.RemoteSocket.Exists}}'` (must print `true`). If it does not, run `systemctl --user enable --now podman.socket` (rootless) or `sudo systemctl enable --now podman.socket` (rootful); without systemd, `podman system service --time=0 &`. On macOS/Windows, `podman machine start` first. Rootful and rootless Podman both work.
+
+With Docker, check with `docker info` and act on what it tells you:
+
+- `docker info` succeeds - you are ready.
+- It fails with "Cannot connect to the Docker daemon" (or similar) - Docker is installed but not running. Do not reinstall it; start the daemon:
+  - Docker Desktop (macOS, Windows): start the Docker Desktop app and wait until it reports running.
+  - Linux with systemd: `sudo systemctl start docker`.
+  - Sandboxes and containers without systemd (common for agent environments): `dockerd` is usually present but nothing starts it. iptables and IP forwarding are often unavailable there, so start it without them, then poll until the daemon answers:
+
+    ```sh
+    if ! docker info >/dev/null 2>&1; then
+      nohup dockerd --iptables=false --ip6tables=false > dockerd.log 2>&1 &
+      until docker info >/dev/null 2>&1; do sleep 1; done
+    fi
+    ```
+
+    Keep the default bridge network - `apify runtime start` publishes ports 3333 and 3000 with `-p`, which needs it. If `docker info` never succeeds, read `dockerd.log` before trying anything else.
+- The `docker` command is missing - installation differs per OS and can need admin rights, so do not improvise it. Point the user at the official Docker docs and let them pick the right path:
+  - Docker Desktop (macOS, Windows, Linux desktop): https://docs.docker.com/get-started/get-docker/
+  - Docker Engine (Linux servers, headless): https://docs.docker.com/engine/install/
+
+`apify runtime install` runs the same engine checks and prints a platform-specific hint when something is missing. It installs `apify/actor-runtime:latest` unless another image is given (for example `apify runtime install apify/actor-runtime:master-5462005` for a pinned build); `apify runtime start` runs whichever image was installed last. Only name an image when the user asks for a specific one.
+
+**Working directory.** Install the preview CLI locally in one dedicated directory rather than globally, so it cannot replace the user's stable `apify` install. Keep the runtime data and the Actor projects you create in the same directory - everything the session produced is then in one place and easy to clean up:
+
+```sh
+mkdir -p apify-runtime-work && cd apify-runtime-work
+npm init -y >/dev/null && npm i apify-cli@runtime
+APIFY=./node_modules/.bin/apify        # use $APIFY for every command below
+```
+
+**Start it and point the CLI at it.** The runtime publishes two ports on `localhost`. Export these variables in the shell you drive the CLI from (they are the same values `apify runtime -h` and `apify runtime start` print):
+
+| Port | Service | Environment variable | Value |
+| ---- | ------- | -------------------- | ----- |
+| 3333 | API (Apify API compatible) | `APIFY_CLIENT_BASE_URL` | `http://localhost:3333` |
+| 3000 | Console (web UI) | `APIFY_CONSOLE_URL` | `http://localhost:3000` |
+
+```sh
+export APIFY_CLIENT_BASE_URL=http://localhost:3333
+export APIFY_CONSOLE_URL=http://localhost:3000
+export APIFY_DISABLE_KEYRING=1
+
+$APIFY runtime install
+$APIFY runtime start --detach --data-dir ./runtime-data   # omit --detach to run in the foreground (Ctrl+C stops it)
+$APIFY login --token local-dev-token                      # the runtime accepts any token
+$APIFY actors ls --json                                   # now talks to the local runtime
+$APIFY runtime stop
+```
+
+`APIFY_DISABLE_KEYRING=1` makes `apify login` store the token in `~/.apify/auth.json` instead of the OS keyring. Set it for agent flows: sandboxes rarely have a keyring, and the runtime token is a throwaway placeholder anyway, so there is nothing worth protecting. Note that this login still replaces whatever credentials `~/.apify/auth.json` held - fine in a throwaway sandbox, but on a developer's machine ask first or have the user run `apify login` with their real token afterwards.
+
+Every `apify` command in that shell (`push`, `call`, `actors`, `datasets`, `api`, ...) then targets the runtime. Unset the variables (or start a new shell) to talk to the Apify cloud again. Do not set them globally for the user without asking - they silently redirect all API traffic.
+
 ## Scheduling and recurring runs
 
 For anything recurring or unattended (e.g. "run every 15 minutes"), use the Apify platform — **not** local `cron`, a `while` loop, or GitHub Actions. Apify Schedules run in the cloud, so they keep firing after your laptop, terminal, or agent session is shut down.