Convert Existing Software into Apify Serverless Actors

Apify Actorization converts existing software into an Actor: a Docker-packaged application that accepts defined JSON input, performs its task, and optionally writes structured JSON output. The workflow analyzes the project, initializes Actor files, adds the relevant SDK lifecycle, configures schemas and metadata, tests the result, and describes deployment to Apify.

Begin by identifying the language, entry point, command-line or environment inputs, configuration files, output forms, and persistence requirements. Inspect existing files and preserve their state before initialization or dependency changes. Confirm the target account and Actor, source license, files and secrets that could be uploaded, network targets, and spending or charging limits.

Use when converting a project for Apify, adding its SDK, wrapping a CLI or script, or migrating a Crawlee project. Local conversion does not authorize cloud upload, Store publication, or monetization. Those steps require their applicable authorization.

Local execution can still contact external targets or cloud storage. Use synthetic fixtures and a test account, inspect storage purge defaults, and preserve unrelated data. A free Actor is not automatically open-source; licensing and source availability remain separate questions.

Inputs include the existing application, its required parameters, expected results, and state-management needs. Initialization creates .actor/actor.json, .actor/input_schema.json, and a Dockerfile if one is absent. Add .actor/output_schema.json when output structure needs one.

JavaScript and TypeScript wrap execution with Actor.init() and Actor.exit(). Python uses async with Actor. CLI-based languages use a wrapper that reads input and pushes results through the Apify CLI. The detailed language-specific paths are selected according to the project.

A local input-file test uses this supplied command:

apify run --input-file ./test-input.json

Verify the chosen language's documented CLI behavior against reviewed versions. Direct SDK or test execution can also be appropriate. Successful local execution is one pre-deployment check alongside a valid build and correctly defined inputs and outputs.

The workflow uses the Apify CLI and the appropriate JavaScript or Python SDK. Check CLI availability and authentication without exposing APIFY_TOKEN. Pin reviewed SDK, CLI, and base-image versions and validate schemas against the corresponding @apify/json_schemas definitions.

Pre-deployment review covers Actor name and description, actor/input/output schemas, a working Docker build, lifecycle wrappers, input access, dataset or key-value-store output, test execution, and generatedBy metadata. Request queues and key-value stores support persistence when needed.

The deployment command uploads and builds the Actor on the platform, so treat it separately from local preparation. Optional Pay Per Event monetization can charge for results, pages, or API calls through configured events. Documentation support may be available through search-apify-docs and fetch-apify-docs when an Apify MCP server is configured.