DEV Community: Dan Stephenson

One Actor, two stores: listing an Apify Actor on Bytewells without forking it

Dan Stephenson — Fri, 23 Oct 2026 12:59:43 +0000

Dan Stephenson, ThoughtPivot

Apify retired rental pricing for Actors on October 1, 2026. Rental Actors that were not moved to pay-per-event became free to use and stopped earning their developers anything. Some developers moved to pay-per-event and are doing well. Others had heavy, recurring renters that a flat monthly price suited better.

Bytewells by ThoughtPivot is a second store for those Actors. It is in private beta now, and the public store opens on Monday, November 2. This post covers the question I get most from Actor developers: do I have to maintain a second codebase?

Short answer: no. Here is how it works, and what it does not do yet.

Your Apify listing stays live

There is no exclusivity. You keep your Apify listing and your Apify pricing. Bytewells is an extra channel for the same Actor. Renters run the built image and never receive your source.

The code doesn't change

Bytewells exposes an Apify-compatible API. Actors written with the Apify SDK and Crawlee, and clients using apify-client, work unchanged; a client points at a different base URL instead of being rewritten.

Inside the Actor, Actor.init(), Actor.getInput(), Actor.pushData() and Actor.exit() behave the way they do on Apify. One codebase ships to both stores.

Import instead of re-listing

Import brings over your Actor's source, README, input schema and pricing, then builds the listing. There are two ways in:

Console: sign in with Apify, pick your Actors, and they come in as draft listings you can review before publishing.
CLI (for tokens and CI): the package is @thoughtpivot/bytewells on npm.

npm install -g @thoughtpivot/bytewells
bw signup --username you
bw import apify you/your-actor --publish

Waitlist developers get hands-on help with the import during the private beta.

How renters pay

Monthly rental, with a free trial you set.
Optional passes for bursty work: Flash (1 hour), Burst (24 hours) and Sprint (7 days). Pay-per-use charges inside a window are capped at the next tier's price, like a transit fare cap.
Compute is billed separately from the renter's prepaid credit at $0.15 per compute unit, against $0.20 on Apify Starter and $0.13 on Apify Business. That is a per-unit rate. What a run costs overall depends on how much compute it uses and on the Actor's own price.

Commission is 10% (20% on Apify), and 0% on renters you bring yourself. Payouts go out monthly through Stripe once your balance reaches $50; check the developer page for the countries Stripe payouts currently cover.

Who this fits

Our September analysis of 291 former rental Actors put the median break-even at 7,411 results a month. Renters pulling more than that paid less with rental plus compute than with pay-per-event at Apify list prices; below it, pay-per-event was cheaper. If your heaviest renters run pipelines, schedules or agents every day, a monthly price may suit them. Full method: https://bytewells.com/apify-rental-alternative

What it doesn't do yet

No paying renters yet. We are building supply and demand at the same time and would rather say so.
Pay-per-usage pricing on Bytewells comes after launch. We started with rentals because that is the model that lost its home on October 1.
Agent pass purchase via MCP is coming. An MCP server that lets agents find Actors, run them and buy passes is on the roadmap. Today, rentals and passes are bought by people.

Get in early

If you have Actors on Apify and want them live when the store opens, join the developer waitlist: https://bytewells.com/developer-waitlist

If rentals were part of your income before October 1, I would like to hear what changed for you, in the comments or by reply.

thoughtpivot

Streaming Koa server-sent events on Bun: the four things that broke, and what Flight 3.0.1 changed

Dan Stephenson — Wed, 21 Oct 2026 13:10:02 +0000

Bytewells by ThoughtPivot

Flight is ThoughtPivot's open-source web framework. Since 3.0.0 it ships flight-bun, a server that runs on Bun.serve and mounts existing Koa backends (export default router.routes()) through a Koa-compat layer. On Oct 18 we pushed 3.0.1 to main. It fixes one thing that matters a lot if you stream: Koa server-sent events (SSE) on flight-bun were buffered until res.end(). The client connected, the server wrote events, and nothing arrived until the stream closed.

The fix touched four separate parts of the stack. Each one was a reasonable choice for request-response traffic and a bug for a stream. This post walks through them, because the same four assumptions are probably sitting in your middleware too.

Commit: https://github.com/thoughtpivot/flight/commit/7db959993b20593e192fbeb599d164751c8ecaf1

The route we wanted to work

This is the usual way to stream from Koa. Nothing Bun-specific:

router.get('/events', (ctx) => {
  ctx.respond = false            // tell Koa we own the response
  ctx.res.writeHead(200, {
    'content-type': 'text/event-stream',
    'cache-control': 'no-cache',
    connection: 'keep-alive',
  })
  const timer = setInterval(() => {
    ctx.res.write(`data: ${Date.now()}\n\n`)
  }, 1000)
  ctx.res.on('close', () => clearInterval(timer))
})

On Node with real Koa, this streams. On flight-bun 3.0.0, it did not.

1. The compat layer waited for `end()`

flight-bun has no Node ServerResponse. The Koa-compat layer hands the route a mock response object, collects what the route writes, and builds a Response for Bun.serve. For a normal handler that is fine: collect the body, then return it.

For a stream, "collect, then return" means "return never." In 3.0.1 the compat layer returns a ReadableStream response as soon as the route starts a body: on writeHead, write, flushHeaders, or when ctx.respond = false is set. Later writes are pushed into that stream. A stream that never calls end() also no longer hangs with an empty body.

Lesson: if your adapter turns a push-style API into a value, decide the response at the first byte, not at the last.

2. Matching was read too early, so live routes fell through to the SPA 404

Flight serves a single-page app by default and answers unmatched paths with the SPA 404. To decide "matched or not", the compat layer read ctx.matched after the middleware chain ran.

Two things broke that. A route that finished the response inside its handler was dropped and replaced by the 404. And with several routers mounted, later routers append to ctx.matched with push, so reading it at the wrong moment missed a match from a router mounted after another one. In 3.0.1 the match is read when the stream opens or when the response finishes.

Lesson: "did anything handle this request?" is a question about time. With streaming, the answer can arrive after your fallback logic has already run.

3. Client disconnect never reached the route

In the example above, cleanup lives in res.on('close'). On Node that fires when the client goes away. On the mock response it never fired, so heartbeats and subscribers kept running for clients that were gone.

3.0.1 wires the request's abort signal to a close event on the mock response. Routes written the normal Koa way now clean up.

Lesson: every layer between the socket and your handler needs to forward cancellation. One layer that swallows it is enough to leak.

4. Gzip and the response cache waited on the stream

Compression middleware buffers so it can compress efficiently. A response cache needs the full body to store it. Both are correct for a JSON response and both stall an event stream.

In 3.0.1 gzip skips text/event-stream and any body that is still streaming, and the response cache skips those bodies too.

Lesson: check content type early and route streams around anything that needs the whole body.

The new setting: `FLIGHT_IDLE_TIMEOUT`

Bun's server closes idle connections after 10 seconds by default. A quiet SSE connection looks idle. 3.0.1 adds FLIGHT_IDLE_TIMEOUT (seconds):

default 10 (Bun's own default)
an explicit 0 disables the server idle timeout
positive fractions round up to at least 1
negative or non-numeric values fall back to 10
values above 255 are clamped to Bun's maximum

Server-sent event responses disable the idle timeout for that request, so you do not have to turn it off globally to keep streams open.

Two things that do not carry over from the Node server

The 3.0.1 docs also spell out two differences that are easy to miss when moving a Flight app from Node to Bun:

No cluster. flight-bun is one process. It does not read FLIGHT_MAX_WORKERS and does not use Node's cluster module. Scale with replicas. (Our benchmark note: on 4 cores, a 4-worker Node cluster served 80.7k req/s against 53.8k for flight-bun. Method and raw data are in bench/BENCHMARKS.md.)
Rate-limit storage is per process. The Bun limiter keeps counters in an in-memory Map and does not use Redis, even when FLIGHT_REDIS_URL is set. Replicas do not share a window, so a limit of 100 across four processes allows 400 requests in the window.

Checklist for your own stack

If you are adding SSE to a framework or adapter you did not write:

Does the adapter return a streaming body at the first write?
Is "was this request handled?" decided after the stream opens, not before?
Does client disconnect reach res.on('close') (or your equivalent)?
Do compression and caching skip text/event-stream?
What is your server's idle timeout, and is it disabled for streams only?

Flight is at https://github.com/thoughtpivot/flight. 3.0.1 is on main; there is no GitHub release tag for it yet. Issues and PRs are welcome.

We build Flight alongside Bytewells by ThoughtPivot, a store for monthly rentals and short passes on Apify-compatible Actors, opening Nov 2. Developer waitlist: https://bytewells.com/developer-waitlist

thoughtpivot

Flight and Scribe on Bun: method, numbers, and where Node still wins

Dan Stephenson — Thu, 15 Oct 2026 16:03:15 +0000

On one pinned CPU core, Flight's Bun runtime served 61,110 requests per second on a hello route. Its Node runtime, at the same commit, served 19,651. Scribe served 21,349 reads per second against 4,998. Flight went from process start to first response in 47 ms instead of 1.18 s.

Two caveats up front, because they change how you should read those numbers:

These are micro-benchmarks (one hello route for Flight, one notes schema for Scribe). They are not application benchmarks.
On 4 cores, a 4-worker Node cluster served 80.7k req/s on Flight's hello route, against 53.8k for one Bun process. The single-core wins do not carry over to a cluster.

This post covers what changed, how we measured, and how to reproduce it. Flight is a Koa-based app server for component-shaped Vue and React apps with Vite. Scribe is a schema-driven data service on Postgres with version history and a Redis schema cache. Both are open source, and both now ship a Bun binary next to the unchanged Node one: flight-bun and scribe-bun.

What was compared

The same commit of each repo. In each case the Node binary is the original runtime path and the Bun binary is the port.

Project	Commit	Node side	Bun side
Flight 3.0.0	`b0d8689`	`flight`: Koa on `node:cluster`, `dist/flight.js` built by `tsc`, `*.backend.ts` loaded through tsx (the loader the README names). A ts-node variant also ran.	`flight-bun`: `Bun.serve`, `src/bun/server.ts` run directly as TypeScript
Scribe 1.3.0	`9a0239f`	`scribe`: Express on `node:cluster`, `dist/scribe.cli.js`	`scribe-bun`: `Bun.serve` transport over the same `src/core.ts`

Method

Hardware and versions. An 8-vCPU Intel Xeon VM with 15 GB RAM, Debian 13, kernel 6.12. It is a shared box with other processes running, so expect noise. Node 20.19.2, Bun 1.4.2, PostgreSQL 17.11, Redis 8.0.2, wrk 4.1.0, hyperfine 1.19.0.

Pinning. Single-core runs: server on core 1, Postgres and Redis on cores 2-3, wrk on cores 4-7 (-t4 -c100, and -c50 for Scribe writes). Four-core runs: server on cores 0-3, Postgres and Redis on 4-5, wrk on 6-7 for Scribe and on 4-7 for Flight.

Holding Node to one worker. Flight has a knob: FLIGHT_MAX_WORKERS=1. Scribe does not, so the harness preloads a tiny script that makes os.cpus() report one CPU, which makes node:cluster fork one worker. The primary process still runs, as it does in production:

// bench/cpus1.cjs
const os = require('os'); const one = os.cpus()[0]; os.cpus = () => [one];

Runs. Every throughput row is a 10 s warmup followed by 3 x 20 s runs, and we report the mean. No non-2xx responses or socket errors appeared in any run. Memory is RSS of the whole server process tree (Node: primary plus workers), taken at idle after one request and again after load. Startup is the time from exec to the first HTTP 200 on a real route, measured with hyperfine (2 warmups, 15 runs).

Workloads. Flight: GET /api/hello returning {"message":"Hello from Flight!"}, in three variants: (a) a Node/Koa router.routes() backend, (b) the same Koa file on flight-bun through its compat layer, (c) a Bun-native route-map backend. Scribe: reads are GET /notes/1. Writes are POST /notes, which runs the shipped create path (two CREATE TABLE IF NOT EXISTS, an ALTER TABLE ... ADD COLUMN IF NOT EXISTS, the insert, and a history insert). Writes were run twice, the second time with tables truncated and the order reversed. Results matched.

Middleware is not identical across the two sides. Each runtime used its own shipped default for a non-dev, non-production mode. Node ran koa-logger (it cannot be turned off, output went to /dev/null), session, CORS and bodyparser. Bun ran security headers, CORS and compression, with no request logging. Neither side rate-limited. That is a real difference in work per request, and we are not claiming it is zero.

Results on one core

Test	Node	Bun	Change
Flight req/s, Bun-native route	19,651 (tsx) / 19,342 (ts-node)	61,110	3.1x
Flight req/s, unchanged Koa route	19,651	38,826	2.0x
Flight p50 / p99, native	4.6-5.0 ms / 10-25 ms	1.5-1.6 ms / 2.9-3.0 ms
Flight p99, Koa on Bun	10-25 ms	6.3-7.2 ms
Flight idle RSS	218 MB (primary + 1 worker, tsx)	27 MB native / 47 MB Koa	about 8x less
Scribe reads req/s	4,998	21,349	4.3x
Scribe read p50 / p99	17-21 ms / 52-65 ms	3.9-4.2 ms / 12.2-12.5 ms
Scribe writes req/s	1,273	2,327	1.8x
Scribe idle RSS	258 MB (primary + 1 worker)	68 MB	about 3.8x less

Startup to first 200 (hyperfine, 15 runs): Flight native 1.182 s (tsx) vs 47 ms +/- 10; Flight with Koa routes on Bun 123 ms +/- 16; Scribe 1.210 s (1 worker) vs 319 ms +/- 34. The Node side includes loading TypeScript through tsx at startup, so part of that gap is the loader, not the runtime.

Where Node still wins: 4 cores

Test	Node cluster, 4 workers	Bun, one process
Flight hello route req/s	80,740	53,835 native / 41,526 Koa
Flight RSS (idle to after load)	550 to 578 MB	28 to 59 MB
Scribe reads req/s	21,455	22,768 (a tie; Postgres on 2 cores is likely the wall)
Scribe RSS (idle to after load)	641 to 700 MB	69 to 105 MB

The shipped Bun runtimes are one process and do not use four cores the way a four-worker cluster does. On Bun today you scale with replicas. We have not yet measured several Bun processes behind reusePort against a Node cluster on the same core count.

What changed in Flight

Bun.serve with a native route table

Instead of passing every request through a Koa middleware chain, flight-bun hands Bun.serve a route table built at startup. A Bun-native *.backend.ts exports an object keyed by path:

// hello.backend.ts (Bun-native contract)
export default {
    '/api/hello': { GET: () => Response.json({ message: 'Hello from Flight!' }) }
}

Discovery scans for *.backend.ts and *.backend.js with Bun.Glob, imports each file, and sorts it by the shape of its default export: an object whose keys all start with / is a route fragment, anything else goes down the Koa path (below). The server is then started with the route table plus a fetch fallback:

server = Bun.serve({
    port: listen.port ?? cfg.port,
    hostname: listen.hostname ?? cfg.hostname,
    routes: app.routes,   // native routes, each wrapped in the middleware chain
    fetch: app.fetch,     // fallback: Koa-compat dispatch, then the SPA
    error: app.error
})

One detail worth knowing: when CORS is on, OPTIONS has to be registered per path, because Bun answers 405 for an unregistered method before any of your middleware runs.

The Koa compat layer

We did not want anyone stuck mid-migration, so an existing export default router.routes() file still boots. The compat layer stands up a private Koa app, adds koa-bodyparser, mounts the discovered middleware, and calls app.callback() with a Node-style request and a mock response built from the Fetch Request:

function callbackToFetch(callback: (req: Readable, res: MockResponse) => void) {
    return async function dispatch(request: Request): Promise<Response | null> {
        const body = request.method === 'GET' || request.method === 'HEAD'
            ? Buffer.alloc(0)
            : Buffer.from(await request.arrayBuffer())
        const req = requestFromFetch(request, body)   // a Readable with method, url, headers
        const res = new MockResponse()                // buffers status, headers, chunks

        await new Promise<void>((resolve, reject) => {
            res.on('finish', () => resolve())
            res.on('error', reject)
            try { callback(req, res) } catch (err) { reject(err) }
        })

        if (!res.flightMatched) return null           // no Koa route matched: fall through to the SPA
        return res.toResponse()
    }
}

res.flightMatched is set from ctx.matched, so an unmatched path returns null and the request falls through to static files. This path is still 2.0x the Node runtime on our test (38,826 req/s). Rewriting the route as a plain (req) => Response handler takes it to 3.1x.

Middleware rewrite

The edge middleware (logging, security headers, CORS, gzip, rate limiting, sessions, response cache) was rewritten against Request and Response with no Koa packages on that path. The composition is a small onion where index 0 is outermost and a middleware may return without calling next:

export function compose(middlewares: Middleware[]): (req: Request, core: Handler) => Promise<Response> {
    return function run(req, core) {
        const dispatch = (index: number): Promise<Response> => {
            const middleware = middlewares[index]
            if (!middleware) return Promise.resolve(core(req))
            return Promise.resolve(middleware(req, () => dispatch(index + 1)))
        }
        return dispatch(0)
    }
}

Sessions and the response cache use Redis when redisUrl is set and fall back to an in-memory store otherwise, so Redis is optional now. We did not run an ablation, so we cannot say how much of the gain comes from the route table, the middleware rewrite, or removing the loader. The two sides also run different default middleware, as noted above.

No build step

Bun loads .backend.ts directly, so production needs neither tsc nor a TypeScript loader. That is part of the startup gap: on the Node side, tsc took 3.5 s (Flight) and 4.4 s (Scribe) before anything ran, and the tsx loader is in the startup path.

What changed in Scribe

We split Scribe's core logic from its Express transport (src/core.ts), then added scribe-bun, a thin Bun.serve transport over that core with a GET /healthz that checks Postgres and Redis. One route suite runs on both runtimes in CI.

Writes improved 1.8x while reads improved 4.3x, and we know why: the create path still runs CREATE TABLE IF NOT EXISTS and ALTER TABLE ... ADD COLUMN IF NOT EXISTS on every insert, on both runtimes. Writes are DDL-bound. Moving DDL off the hot path is the obvious next optimization. A second known cost: the Redis-cache and default-schema path builds a new Ajv instance and compiles on each request. Only discovered schema files are cached in-process.

Toolchain timings

	Node toolchain	Bun
Flight install, cold cache	`npm ci` 6.11 s	`bun install` 0.44 s
Scribe install, cold cache	6.42 s	0.86 s
Scribe test cycle	`npm test` 10.59 s (tsc build + `node --test`, 40 tests)	`bun test` 0.87 s (51 tests: the same 3 shared files plus Bun-only checks)

CI and the docs still run npm ci, even in the Bun CI job, so bun install is optional today. Flight's two test suites differ (30 Node tests vs 6 Bun tests), so we do not compare them.

How to reproduce

The scripts and raw outputs are in each repo's bench/ folder: https://github.com/thoughtpivot/flight/tree/main/bench and https://github.com/thoughtpivot/scribe/tree/master/bench. You need wrk, hyperfine, taskset (Linux), and Bun. For Scribe you also need local Postgres and Redis and SCRIBE_APP_DB_PASS set.

# Flight, one core: c = Bun-native, b = Koa file on Bun, t = Node + tsx, a = Node + ts-node
source bench/env.sh
bench/throughput.sh c 4003 1          # server on core 1, wrk on cores 4-7
W=4 bench/throughput.sh t 4004 0-3    # Node cluster on 4 cores

# Scribe, reads and writes on one core
bench/throughput.sh sb 5002 1 100 /notes/1
bench/throughput.sh sb 5002 1 50  /notes bench/post.lua

throughput.sh does the 10 s warmup, the three 20 s runs, and the idle and after-load RSS of the whole process tree. startup.sh times exec to the first 200. Run it a few times and expect some spread on a shared machine. If your numbers differ, open an issue with them. We would like to see where they land.

What we have not measured yet

End-to-end Flight to Scribe to Postgres with a real Vue or React app
Several Bun processes (reusePort, or replicas) against a Node cluster on equal cores
Container image size and Kubernetes pod cold start
Production-mode Flight with compression, Redis sessions, rate limiting and static SPA serving on both sides
A soak of an hour or more for memory growth
CI wall time if the Bun job switches to bun install

One known issue: express-bunyan-logger records a request in src/bun/dependencies.test.ts is flaky under Bun. It failed in 2 of about 11 local runs.

Try it

npm install @thoughtpivot/flight   # then run: flight-bun   (needs Bun on PATH)
npm install @thoughtpivot/scribe   # then run: scribe-bun   (needs Bun on PATH, plus Postgres and Redis)

flight-bun needs Bun on your PATH and listens on port 3000 by default (set FLIGHT_PORT to change it). scribe-bun also needs Bun on your PATH, and it needs a running Postgres and Redis.

The Node binaries (flight, scribe) are unchanged.

Credit

Early Bun research and benchmarks for Flight and Scribe by Vasilen Lyubomirov (github.com/VasilenL), whose work helped start this.

Source: github.com/thoughtpivot/flight and github.com/thoughtpivot/scribe

#thoughtpivot

Proxy bills are up and AI scraping is coming. What that means if you sell Apify Actors

Dan Stephenson — Fri, 09 Oct 2026 12:52:20 +0000

Disclosure: I work on Bytewells by ThoughtPivot, a second store for Apify Actors. Bytewells is an independent marketplace and is not affiliated with, endorsed by, or sponsored by Apify.

In December 2025, Apify and The Web Scraping Club surveyed hundreds of web scraping professionals. The report came out on Jan 29, 2026, and two of its findings matter if you build and sell Actors.

1. Running scrapers keeps getting more expensive

65.8% of respondents reported increased proxy usage.
58.3% said their proxy spending went up year over year.
More than 62% reported higher infrastructure spending, driven largely by stronger anti-bot protections.

If you sell an Actor, that cost lands somewhere: in your price, in your margin, or on your renter's compute bill. A browser-based Actor going through residential proxies costs far more per run than a plain HTTP fetch, and a per-result price that ignores this can lose money on every run. Two habits help on any store. Measure compute per result before you set a price, and don't route traffic through a proxy the target doesn't require.

2. AI-assisted scraping is growing, but trust isn't there yet

45.8% of respondents use AI in their scraping workflows and 54.2% don't. The holdouts cited trust in results, cost, integration pain and unreliable performance on some sites. Still, 66.2% plan to try AI-assisted tools, and 72.7% of current AI users report productivity gains.

For Actor developers, the practical change is a new kind of buyer: agents. An agent rarely wants a month of access. It wants an hour or a day, it wants a price it can read before it runs, and it needs a well-described input schema to call your Actor correctly.

How we're responding with Bytewells

We're building Bytewells by ThoughtPivot around those two pressures:

Commission: 10% of each rental and pass charge, against 20% on Apify, and 0% on renters you bring yourself. Stripe's card and billing fees pass through at cost, so a typical $17.50 rental nets you about 85%.
Pricing models: monthly rentals, plus optional Flash (1 hour), Burst (24 hours) and Sprint (7 days) passes for bursty and agent workloads. Apify retired rental pricing on Oct 1, 2026, so this brings that option back for your heavy renters.
Compute: $0.15 per compute unit, paid by the renter separately from the rental. That's below Apify Starter ($0.20) and above Apify Business ($0.13), so it isn't the cheapest option for every buyer.
No exclusivity: the Apify SDK and apify-client work unchanged, so one codebase can ship to both stores and your Apify listing stays as it is.

The reality check

Bytewells is in private beta, and the public launch is planned for Nov 2, 2026. We have no paying renters yet. Pay-per-event pricing isn't available at launch, so if your Actor's business model depends on Actor.charge(), Bytewells doesn't fit that model yet. If your buyers are recurring high-volume teams, or agents that work in short bursts, listing on Bytewells too may be worth it. If they're occasional long-tail users, pay-per-event on Apify probably still suits them better.

Source: State of web scraping report 2026

If you sell Actors and want in, developers on the waitlist are invited first: https://bytewells.com/developer-waitlist

DEV Community: Dan Stephenson

One Actor, two stores: listing an Apify Actor on Bytewells without forking it

Your Apify listing stays live

The code doesn't change

Import instead of re-listing

How renters pay

Who this fits

What it doesn't do yet

Get in early

thoughtpivot

Streaming Koa server-sent events on Bun: the four things that broke, and what Flight 3.0.1 changed

The route we wanted to work

1. The compat layer waited for end()

2. Matching was read too early, so live routes fell through to the SPA 404

3. Client disconnect never reached the route

4. Gzip and the response cache waited on the stream

The new setting: FLIGHT_IDLE_TIMEOUT

Two things that do not carry over from the Node server

Checklist for your own stack

thoughtpivot

Flight and Scribe on Bun: method, numbers, and where Node still wins

What was compared

Method

Results on one core

Where Node still wins: 4 cores

What changed in Flight

Bun.serve with a native route table

The Koa compat layer

Middleware rewrite

No build step

What changed in Scribe

Toolchain timings

How to reproduce

What we have not measured yet

Try it

Credit

Proxy bills are up and AI scraping is coming. What that means if you sell Apify Actors

1. Running scrapers keeps getting more expensive

2. AI-assisted scraping is growing, but trust isn't there yet

How we're responding with Bytewells

The reality check

1. The compat layer waited for `end()`

The new setting: `FLIGHT_IDLE_TIMEOUT`