Remote vs Local instances

With Bytebot, you can generate actions that can be run on a remote or local instance. For most users, a Bytebot-managed remote instance is the best fit; it simplifies testing and automatically handles initialization and shut-down for you. However, if you want a more controlled instance, then running Bytebot on a local Puppeteer instance may be preferred.

Remote, Managed Browsers (recommended)

When using Bytebot’s remote namespace, Bytebot creates a browser for you on the cloud, leveraging Puppeteer under-the-hood. When you create actions and extractions, Bytebot will automatically run this on the remote browser. At any time, you can check on the status of the browser, and you will be able to observe the status immediately after every BrowserAction set is auto-executed. Once you end your session, the remote browser will be automatically destroyed.

Generally speaking, code that leverages a remote browser is half the length than corollary code that uses a local browser. However, you do not gain full control over the browser instance, and cannot readily leverage Puppeteer features such as screenshot or PDF generation.

Local Puppeteer Browsers

Alternatively, you can import Puppeteer and manually initialize a browser. This may be ideal if you already use Puppeteer in a local workflow and are using Bytebot to improve your existing system. However, when using a local Puppeteer instance, you are responsible for initializing your browser, executing Bytebot-generated BrowserActions, and destroying your browser.

One benefit of using a local Puppeteer instance is that you can take advantage of all of Puppeteer’s features, including screenshot or PDF generation.

Next Steps

After weighing the pros and cons of each, choose the best approach for you and create your first Bytebot action.