> ## Documentation Index
> Fetch the complete documentation index at: https://www.octoparse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Local extraction
> Run Octoparse tasks on your own computer for direct control over the execution environment, sessions, and collected data.
Local extraction runs an Octoparse task on your own computer. The target website is opened and processed from your local environment, collected data is saved directly on the device, and you can watch the workflow, inspect its output, and intervene while it runs.
**Local extraction is available for free.** It is a practical choice for testing, small-volume collection, and workflows where control over the execution environment or data location matters more than unattended scale.
Choose local extraction when you want to collect data without consuming cloud extraction resources. For 24/7 operation, large-scale collection, or runs that must continue independently of your computer, use [cloud extraction](/docs/en/platform/local-vs-cloud).
## Why run locally
### Collect locally for free
You can build, test, and run tasks locally without paying for cloud extraction capacity. This makes local extraction suitable for:
* Learning and evaluating Octoparse
* Building and debugging new tasks
* One-time or small-volume data collection
* Running occasional tasks when cloud scale is unnecessary
Your own computer supplies the processing, memory, storage, power, and network connection. The absence of cloud extraction charges does not remove the operational cost of maintaining that local environment.
### Direct control and visibility
A local run stays close to the task-building experience. You can observe page navigation and extraction as they happen, compare the browser with the Data Preview, pause or stop the run, and adjust the task when a selector, wait condition, login, or page action behaves unexpectedly.
This makes local extraction especially useful for:
* Testing a new or recently changed workflow
* Diagnosing website-specific behavior
* Checking missing, incorrect, or repeated values
* Verifying login, pagination, scrolling, and detail-page actions
* Running a small, one-time collection under direct supervision
### Use your local environment
Requests originate from the network environment where Octoparse is running. The task can therefore use conditions tied to that environment, such as a local IP address, regional access, an authenticated browsing session, or access available through your organization’s network.
This can help when a task works in your browser but behaves differently on a cloud node. You also retain more control over the device environment: approved supporting software, network tools, and system settings can be managed according to your workflow and organizational requirements.
That flexibility comes with responsibility. Local results depend on your machine, network, browser session, installed software, and system configuration. Environment changes can affect task behavior.
### Keep the active run on your device
During local extraction, task execution and collected data are handled primarily on the local device. This gives you more direct control over where extraction data is stored and can support policies that require data to remain in a user-managed environment. Exact data handling can vary by task, account, export destination, and enabled service.
Local execution does not by itself guarantee privacy or compliance. Consider the complete data path:
* The target website still receives requests from your network.
* Signing in, syncing task configurations, sharing work, or using an online export can still transmit related information to the applicable service.
* Exported data is subject to the security and access controls of its destination.
* Anyone with access to the computer or local output may be able to access the collected data.
If data handling requirements are strict, confirm the task, account, export destination, device controls, and organizational policy together.
### Control credentials and sessions
Local extraction can be useful for websites that rely on a session established in the desktop environment. It may reduce the need to reproduce that browsing state in a separate cloud environment.
Treat login credentials and cookies as sensitive. Use an approved account, protect the device, limit access to task files and outputs, and avoid collecting data beyond what you are permitted to access.
## Recover interrupted work with Checkpoint resume
The main operational tradeoff of local extraction is device dependency: the run relies on your computer, Octoparse client, power, and network connection. Octoparse 10.2 reduces the cost of an interruption with [Checkpoint resume](/docs/en/platform/checkpoint-resume).
For a supported interactive local run, Octoparse records extraction progress such as output rows, loop position, and unfinished work. If the run stops before completion, starting the task again can present two choices:
* **Resume** restores the saved run and continues toward the remaining data.
* **Re-collect** discards the checkpoint and starts from the beginning.
Octoparse validates the checkpoint against the current task before using it. If the task or input URLs changed, the checkpoint is missing or damaged, or the saved state cannot be matched safely, the task must start fresh. Scheduled local runs also start fresh rather than waiting for a resume decision.
Checkpoint resume makes longer local collections more practical, but it does not remove the need to keep the device available or verify the final dataset after an interruption.
## Local extraction tradeoffs
| Advantage | What you remain responsible for |
| ------------------------------------------- | ------------------------------------------------------------- |
| Run local extraction for free | Supply and maintain the computer, storage, power, and network |
| Observe and control the run directly | Keep Octoparse and the computer running |
| Use local network and session conditions | Maintain network stability and valid login sessions |
| Keep collected data on a managed device | Secure the device, local data, and export destination |
| Customize the supporting device environment | Maintain compatible software and system settings |
| Diagnose workflow behavior in real time | Review errors and correct the task when the website changes |
| Resume supported interrupted runs | Confirm the checkpoint is valid and verify the completed data |
## Limits of local extraction
Local extraction trades cloud scale and managed infrastructure for direct control:
* **Limited scalability:** A local run is constrained by the CPU, memory, storage, and network capacity of one computer.
* **Device-dependent reliability:** Power loss, sleep, network interruption, application closure, or an operating-system issue can stop the task.
* **Higher operational responsibility:** You maintain the hardware, operating system, software environment, storage, security controls, and network availability.
* **Not ideal for unattended operation:** The computer must remain available. Local scheduling is possible, but the task still depends on the device at the scheduled time.
[Checkpoint resume](/docs/en/platform/checkpoint-resume) reduces the cost of some interruptions by preserving supported run progress. It does not provide the always-on availability or elastic resources of cloud extraction.
Use [cloud extraction](/docs/en/platform/local-vs-cloud) when the task must run after your computer is turned off, operate on a recurring unattended schedule, or use cloud resources for production-scale collection.
## Related pages
Compare execution environments and choose the right run mode.
Continue a supported interrupted local run from saved progress.
Review credential, export, account, and compliance considerations.