chore: Update Actor development skill with more information about standby mode#35
Conversation
nmanerikar
commented
Apr 1, 2026
nmanerikar
commented
- Add a quick section in the main Actor development skill about when to choose standby mode
- Add essential details about standby mode to the separate standby reference
- Update the actor.json reference to add a couple of standby-specific params
tobice
left a comment
tobice
left a comment
There was a problem hiding this comment.
Nice!
Should we ask @patrikbraborec for review? He is responsible for general DX.
raethlo
left a comment
raethlo
left a comment
There was a problem hiding this comment.
Thanks Nish, overall looks great. One thing I am not sure about is omitting standby from scraping/crawling use cases in the instructions. What do you think?
| } | ||
| ``` | ||
|
|
||
| ### OpenAPI Schema (`webServerSchema`) |
There was a problem hiding this comment.
[nit] I would consider instructing to use a openapi tooling middleware if a framework is used (like express/hono/flask/fastapi whatever) and ideally also to define schemas/types annotations in code too -- we can iterate on this later
There was a problem hiding this comment.
Let's not try to confuse it with more tool mentions. I've just added a line to make it ensure that the schema confirms to the spec. As you say, we can iterate on this later.
| Use Standby when the Actor must respond to HTTP requests in real time - API endpoints, webhook receivers, real-time data lookups, MCP servers, or any synchronous request-response pattern. | ||
|
|
||
| You can recognize a standby Actor by checking the `usesStandbyMode` property in `.actor/actor.json`. Only implement the readiness probe if this property is set to `true`. | ||
| Do NOT use Standby for batch jobs (scraping, crawling, data pipelines, scheduled exports). Use the default batch mode instead. |
There was a problem hiding this comment.
I am not sure if this is the case, there are legit use cases where you might want to expose a scraping/crawling workflow with a standby to handle bursts and benefit from the auto-scaling and/or optimize resource util (especially if the input to scrape is not well defined in advanced)
|
|
||
| See [references/standby-mode.md](references/standby-mode.md) for complete standby mode documentation including readiness probe implementation for JavaScript/TypeScript and Python. | ||
| **When to use Standby vs. batch mode:** | ||
| - **Standby mode** - Actor runs as a persistent HTTP server responding to requests in real time. Use when the user needs: an API endpoint, webhook receiver, real-time data lookup, MCP server, or any synchronous request-response pattern. Signal words: "API", "endpoint", "webhook", "real-time", "server", "on-demand", "low latency". |
There was a problem hiding this comment.
as mentioned above, scraping can also be a valid use case, maybe it's more about the nature of frequency of calls and nature of the input? like, "one-url scraping jobs that come in bursts that you don't know in advance" (i.e. a standby handling a fleet of browser instances and exposing "scraping api")
|
Hi, thanks! I missed the notification, I will check it today. |
raethlo
left a comment
raethlo
left a comment
There was a problem hiding this comment.
Looks good ✅ , just one small comment
| 1. Start the HTTP server directly (e.g., `node src/main.js` or `python src/main.py`) | ||
| 2. Send requests with curl/httpie to verify endpoints | ||
| 3. Test the readiness probe: `curl -H "x-apify-container-server-readiness-probe: true" http://localhost:<port>/` | ||
| 4. Deploy with `apify push` and test via the Standby URL. Local Standby URLs use the format `http://<username>--<actor-name>.localhost:8003/<path>?token=<APIFY_TOKEN>` (e.g., `http://meaningful-sand--standby-actor.localhost:8003?token=apify_api_...`) |
There was a problem hiding this comment.
this seems like sth that works only if you'd have the platform spun up locally -- but maybe I'm missing sth
5 participants
