Decide whether this move earns its cost
A recurring job signs in, performs a permitted browser task and records its result without an interactive caller. Overlapping triggers must not create unintended duplicate work.
Steel's managed and self-hosted choices make infrastructure ownership a concrete deciding factor. Keep that option on the shortlist when operating the browser is intentional; evaluate Notte when owning fewer execution and authentication components is the actual goal.
Notte is a natural candidate when a scheduled Python handler and its browser should share an execution platform. Check schedule behavior and browser duration independently.
Keep an existing scheduler or a provider-native execution language when it already meets the job contract and a Python port would add unnecessary maintenance. A triggered request is not proof of completion.
Keep the result contract stable
A test schedule with an explicit timezone, fixed inputs and a destination that exposes whether the operation ran once.
Each scheduled attempt has a terminal execution record and a verified business result, and the expected browser cleanup occurs.
Preserve the evidence contract across the move: Scheduled time and timezone, execution ID, business result and overlap outcome.
Map the workflow's resources
| Requirement | Steel | Notte |
|---|---|---|
| Code execution | External worker | Python Functions |
| Scheduled execution | External scheduler | Native |
| Recordings / replay | Documented | Documented |
Sources: docs.steel.dev [1] ↗docs.steel.dev [2] ↗docs.notte.cc [3] ↗docs.notte.cc [4] ↗
Where the code runs
Steel: The reviewed browser documentation establishes sessions, profiles and credentials. It does not establish a hosted Python handler with deployment and invocation APIs. An external worker can control a Steel browser; price and operate that worker separately.
Notte: Functions deploy Python code with a run() entry point. Invoke them over HTTP or with an SDK, inspect run history, and roll back code by redeploying an earlier version as the latest version.
Deployment ownership
Steel: Compare managed Steel with the documented self-hosted path explicitly. Self-hosting gives the team infrastructure responsibility that a hosted browser subscription would otherwise cover.
Notte: Use a remote browser from your existing process or deploy the browser automation as a Notte Function. These choices put lifecycle, scheduling and monitoring responsibilities in different places.
Pricing model
Steel: Hosted browser plans and a self-hosted browser have different cost structures. For self-hosting, include the worker, compute, networking, storage and operations rather than assigning the open-source code a zero operating cost.
Notte: The public usage rates are $0.01 per browser-hour, $0.05 per Function-hour and $10 per GB of managed proxy traffic. Paid plans return their price as usage credits. Price the relevant meters and plan eligibility for the workload.
Sources: docs.steel.dev [1] ↗notte.cc [2] ↗
Cut over one responsibility at a time
For this Steel-to-Notte migration, keep the business assertion outside provider resource management. Source profile, connection, file and execution IDs are not valid target IDs; use a documented transfer path or establish the corresponding resource in Notte.
Retain source job history and a rollback route until the target pilot passes. A migration checklist is not evidence that saved state or runtime behavior is automatically portable.
- Pause the target schedule while replaying a fixed input manually.
- Verify the Python handler's result and browser cleanup before enabling a canary schedule.
- Run only one authoritative production schedule during cutover and preserve source run history.
Sources: docs.steel.dev [1] ↗docs.notte.cc [2] ↗docs.notte.cc [3] ↗
A proposed acceptance case
This is an evaluation design, not a claim that this workflow has been executed successfully on every provider.
| Part of the test | Required observation |
|---|---|
| Controlled input | A test schedule with an explicit timezone, fixed inputs and a destination that exposes whether the operation ran once. |
| Pass condition | Each scheduled attempt has a terminal execution record and a verified business result, and the expected browser cleanup occurs. |
| Negative case | Let one test run outlive the next trigger. Inspect the overlap policy and verify the intended number of website changes. |
| Evidence to retain | Scheduled time and timezone, execution ID, business result and overlap outcome. |
A reason to delay or keep the source
Let one test run outlive the next trigger. Inspect the overlap policy and verify the intended number of website changes.
Steel: Hosted and self-hosted Steel are different operating choices. A cloud feature's documentation does not establish identical packaging, retention or operational support in a self-hosted installation.
Delay cutover when the target's selected plan, required artifact path or supported website-account flow is not established. Resolve that gap before moving real jobs, even if the rate comparison favors the target.
Sources: docs.steel.dev [1] ↗notte.cc [2] ↗