What is TinyBrowser? Managed Browser Infrastructure for AI Agents
You give an AI agent a task that requires a live website. Your code can decide which page to open, but someone still has to run the Chromium browser it uses.
As concurrent sessions grow, you need to provision more browsers, manage proxy routing, and deal with sites that challenge automated traffic. Those jobs take time away from building the agent’s logic.
What is TinyBrowser?
TinyBrowser is the managed browser infrastructure layer of the TinyFish platform.
Instead of starting and maintaining Chromium on your own servers, your application creates a hosted browser session and connects to it remotely. Your existing browser automation can control that session using Playwright or Puppeteer, or directly through the Chrome DevTools Protocol (CDP).
The most important distinction is simple:
TinyBrowser gives you the browser. Your code decides what the browser does.
For example, your application might tell the browser to:
- open a page
- wait for JavaScript to render
- click a button
- fill a form
- capture a screenshot
- inspect an element
- or download a file
TinyBrowser provides the Chromium environment those commands run inside. It does not independently decide which page to visit or how to complete a task.
If you want TinyFish to take a goal and determine the website steps itself, that is a TinyAgent workflow instead.
Key takeaway: TinyBrowser manages the browser infrastructure. It does not replace your automation logic.
What problem does TinyBrowser solve?
Writing browser automation and operating browser infrastructure are two different jobs.
You may already have code that knows exactly what to do:
Open the page
Wait for the form
Enter the values
Submit
Read the confirmationThe automation logic may be perfectly fine. The operational work around it is where things get more complicated.
Running Chromium in production can mean managing:
- browser provisioning
- concurrent sessions
- session isolation
- browser crashes or hung processes
- resource consumption
- proxy routing
- browser scaling
- and websites that challenge automated traffic
That infrastructure grows alongside the number of browser sessions your application needs.
TinyBrowser separates those concerns.
Your application keeps control of the workflow, while TinyFish runs the browser environment, session infrastructure, residential proxy routing, and access-handling layer behind it.
This is useful when you want to keep writing your own browser logic but no longer want browser operations to become a separate infrastructure project.
TinyBrowser’s infrastructure can reduce some of the friction associated with sites that challenge automated browsers, but that does not mean every website will always permit automated access. Websites can still block or restrict sessions.
How does TinyBrowser work?
A TinyBrowser workflow has a straightforward shape:
create a session → connect your code → control the browser → close the session
1. Your application creates a browser session
The application starts by requesting a managed Chromium session from TinyBrowser.
TinyFish creates the remote browser and returns a connection endpoint that your application can use.
You do not need to start Chromium manually on the same server that runs your application.
2. Your code connects to the browser
Your automation connects to the hosted session through a familiar browser interface.
TinyBrowser supports:
- Playwright
- Puppeteer
- Chrome DevTools Protocol (CDP)
That means a developer who already has browser automation code does not need to adopt an entirely different automation model just to move the browser into the cloud.
For example, Playwright can connect to the remote browser through its CDP connection URL.
The browser runs on TinyFish infrastructure. Your Playwright or Puppeteer code still controls it.
3. Your application decides what happens
Once connected, your application sends browser commands through Playwright, Puppeteer, or CDP. Existing workflows may need adjustments for remote execution, so test the browser features your application relies on before moving production traffic.
Your code might:
- navigate to a URL
- wait for a selector
- interact with page elements
- fill known fields
- inspect rendered content
- take screenshots
- or download files
This is where the difference between TinyBrowser and TinyAgent becomes important.
TinyBrowser does not look at a high-level task such as:
Find this company’s latest invoice and download it.
and independently decide how to accomplish it.
Your code supplies those steps.
TinyBrowser supplies the browser they execute in.
4. TinyFish manages the browser infrastructure
While your application controls the session, TinyFish handles the operational browser layer behind it.
That includes managed Chromium sessions, infrastructure scaling, residential proxy routing, and access handling.
When your application is finished, the browser session can be closed rather than leaving you to maintain a persistent browser process yourself.
Pro tip: If your application already knows the exact browser steps, you do not need to introduce an autonomous agent simply to avoid hosting Chromium. Keep the logic and move only the browser infrastructure.
Already have the browser logic?
Run your Playwright or Puppeteer automation against a managed Chromium session instead of hosting the browsers yourself.
What does TinyBrowser provide?
TinyBrowser is not a task-planning layer. Its job is to give applications a managed environment in which their browser automation can run.
| TinyBrowser capability | What it means for your application |
|---|---|
| Managed Chromium | Run remote Chromium sessions without operating the browser fleet yourself |
| Playwright, Puppeteer, and CDP support | Control the browser using familiar automation interfaces |
| Isolated browser sessions | Run browser workloads independently across concurrent sessions |
| Managed proxy routing | Route browser traffic without operating the proxy infrastructure yourself |
| Infrastructure-level access handling | Reduce some of the friction that automated browsers encounter on modern websites |
The boundary matters as much as the features.
TinyBrowser does not automatically decide:
- which selectors your workflow should use;
- which page should come next;
- how to recover from application-specific errors;
- what information should be extracted;
- or whether a task has been completed correctly.
Those decisions belong to your application.
That is what makes TinyBrowser useful for developers who want browser infrastructure without giving up browser control.
What can you use TinyBrowser for?
TinyBrowser fits applications that need a real browser while keeping control of browser actions in their own code. That controller can be a fixed automation script or an AI agent that chooses actions as the task progresses.
Run existing Playwright or Puppeteer automation in the cloud
An existing Playwright script can open a dashboard, navigate to a report, and save the downloaded file. TinyBrowser provides the managed Chromium session for that workflow, while your application retains control of the steps.
This is one of the clearest reasons to use a cloud browser: the automation logic stays in your code while the browser runtime moves into managed infrastructure.
Render and inspect dynamic webpages
Some webpages depend heavily on JavaScript and need to be loaded in a real browser before the application can inspect their rendered state.
Your automation may need to wait for a component to appear, inspect an element after rendering, or interact with content that does not exist in the initial page response.
TinyBrowser gives that workflow a real Chromium session.
Your code still decides what to inspect.
Run scripted browser workflows
TinyBrowser can also support deterministic workflows where the application already knows each browser action.
For example, your code might:
- navigate through a predefined sequence of pages;
- fill known form fields;
- capture screenshots for QA;
- download a report;
- inspect a rendered dashboard;
- or verify that an expected element appears.
The browser executes the commands your application sends.
It does not plan the workflow itself.
Work with authenticated browser sessions
Some browser workflows need a logged-in state.
Your application can control the login process and subsequent browser actions inside a managed session when the workflow is authorized to access that account.
This does not mean TinyBrowser independently manages the identity or decides how to authenticate.
Direct TinyBrowser sessions are isolated and do not automatically preserve cookies or browser storage between runs. TinyFish’s Browser Context Profiles provide a separate setup-and-save workflow for reusing login state in TinyAgent runs.
Why use a managed browser instead of running Chromium yourself?
You can run Chromium yourself.
For some applications, that is the right choice.
The real decision is whether browser infrastructure is something your team wants to own.
Your automation logic stays yours
Moving to a managed browser does not mean replacing your Playwright or Puppeteer code with an autonomous agent.
Your application can retain control over every browser action.
That is useful when the workflow is deterministic, tested, and already encoded in your application.
Browser infrastructure can scale separately
The application deciding which page to visit and the infrastructure running Chromium do not need to be the same system.
Separating them means your application can request browser capacity as workloads grow without also turning browser provisioning into part of the product code.
Proxy routing is part of the browser environment
Browser automation often becomes more complicated once teams have to manage both the browser fleet and its network layer.
TinyBrowser includes managed proxy routing so developers do not need to operate that infrastructure separately for every browser session.
You do not have to build an anti-bot layer from scratch
Sites may inspect browser behavior, fingerprints, IP reputation, and other signals associated with automated traffic.
TinyBrowser handles parts of that access problem at the infrastructure layer.
It is still important to set realistic expectations: managed anti-bot handling reduces friction; it does not guarantee access to every website.
When self-hosting may still make sense
TinyBrowser is not automatically the right choice for every browser workload.
Running Chromium yourself may still make sense if:
- you only run a handful of browser sessions;
- browser infrastructure is already well-supported internally;
- you require a highly customized browser environment;
- or you specifically want full control over the hosting layer as well as the browser logic.
TinyBrowser becomes more useful when browser infrastructure is work you no longer want to own, but browser behavior is something you still want to control.
Key takeaway: The reason to use TinyBrowser is not that writing Playwright is difficult. It is that operating the browser fleet behind Playwright becomes its own infrastructure problem.
TinyBrowser vs. TinySearch vs. TinyFetch vs. TinyAgent
The four TinyFish primitives solve different parts of a web workflow.
| TinyFish product | Use it when you need to… |
|---|---|
| TinySearch | Find relevant web sources when you do not know the URL |
| TinyFetch | Retrieve page content when you already know the URL |
| TinyBrowser | Control a managed Chromium browser using your own automation code |
| TinyAgent | Give TinyFish a goal and delegate a multi-step website task |
Use TinySearch when you need to find the page
The application knows what information it wants but does not know where it lives. TinySearch starts with a query and returns relevant sources.
Use TinyFetch when you already know the page
The application already has the URL and needs the page content.
TinyFetch retrieves and processes it.
Use TinyBrowser when your code already knows what to do
Your application owns the browser workflow.
TinyBrowser gives that code a managed Chromium environment in which to run.
This is the right fit when you want to keep control of individual browser actions without maintaining the browser infrastructure yourself.
Use TinyAgent when you want to delegate the steps
TinyAgent works at a different level.
Instead of scripting every interaction yourself, you give TinyAgent a goal and it determines how to navigate the website and complete the task.
A simple way to remember the difference is:
TinyBrowser: you write the steps.
TinyAgent: you provide the goal.
For a deeper breakdown, see Headless Browser vs. AI Agents: When to Use Each.
Know the steps already? Keep control of them.
Connect your existing automation to a managed TinyBrowser session.
How much does TinyBrowser cost?
TinyBrowser costs $0.002 per browser minute, billed against your prepaid TinyFish Wallet. There is no recurring subscription or monthly minimum.
Standard accounts support five concurrent browser sessions. Higher concurrency can be arranged for larger workloads.
TinySearch and TinyFetch remain free within their published usage limits.
You can see the current plan details on the TinyFish pricing page.
How to get started with TinyBrowser
The basic setup is:
- Create a TinyFish account and API key, and store the key in a server-side environment variable rather than your source code.
- Request a TinyBrowser session.
- Get the CDP/WebSocket connection URL returned for that session.
- Connect using Playwright, Puppeteer, or raw CDP.
- Run your existing browser automation.
- Explicitly terminate the remote session through the Browser API when the workflow finishes or fails.
Use the session’s DELETE endpoint for cleanup, and configure an inactivity timeout as a fallback.
If you already use Playwright or Puppeteer, the important change is mostly where Chromium runs.
Your application still controls the browser.
For a broader walkthrough of this architecture, see What Is a Cloud Browser?
Keep the browser logic. Stop running the browser fleet.
If your application already knows which browser actions to take, you do not necessarily need an autonomous agent. You need a reliable environment where that automation can run.
TinyBrowser gives Playwright, Puppeteer, and CDP-based applications managed Chromium sessions while keeping workflow decisions in your code.
Your script. TinyFish’s browser infrastructure.
Related reading
AI disclosure
Content on this website may be created or refined with the assistance of AI tools and is subject to human editorial review.
