Eight Things I Wish I'd Known Before Building on Tencent EdgeOne Makers

Ravi Arnan Irianto — Thu, 13 Aug 2026 11:28:36 +0000

I spent a weekend shipping a small tool on Tencent EdgeOne Makers, and the interesting part wasn't the code. It was the gap between what the documentation says and what the runtime actually does. Every one of the eight things below cost me a deploy cycle to discover, and none of them are written down anywhere I could find.

If you are about to build your first agent on this platform, this article is the afternoon I already lost, handed to you. None of these are reasons not to use EdgeOne Makers. I would pick it again. They are just the things nobody tells you on day one.

The tool is Rubric. You paste a URL, and it grades the page. Thirteen checks in two categories: six on the response headers, seven on the rendered document. example.com scores 45 D, because it sends no security headers at all. The code is on GitHub.

I picked it deliberately. EdgeOne Makers gives agents a sandbox with a real browser in it, and I wanted to build something that would be impossible without that, not another wrapper around a chat completion. Reading response headers is something any serverless function can do. Counting the images that are missing alt text requires a browser that has actually built the document. That difference turned out to be the first and most important thing I learned.

1. `context.sandbox` is injected into `agents/`, not `cloud-functions/`

EdgeOne Makers gives you two folders. cloud-functions/ is an ordinary stateless request handler. agents/ is the session-oriented one. The docs describe the injected context object (request, env, store, tools, sandbox, tracer) as though it were the same context everywhere.

It is not. A handler in cloud-functions/ never receives sandbox. If you were planning a lightweight function that opens a browser, that plan does not exist. This single fact decided the entire layout of my repo before I wrote a line of audit logic.

2. Every request needs a `makers-conversation-id` header

This is the one that will waste your afternoon. Call your deployed agent without that header and the platform answers 400 before your handler ever runs. Your logs stay empty, because nothing of yours executed. A perfectly healthy endpoint looks stone dead.

The value just has to be 6-36 characters of [0-9a-zA-Z-_.]. Any session string will do:

curl -sS \
  'https://edgeone-site-auditor.edgeone.dev/audit?url=https://example.com' \
  -H 'makers-conversation-id: your-session-id'

It makes sense once you know it: agents are session-scoped, and context.store is keyed by that conversation id. But nothing tells you it is mandatory, and the failure looks like a deployment problem rather than a missing header.

3. The POST body does not reach your handler

await request.json() came back empty on every deployed attempt. The platform appears to consume the body before the handler sees it. ?url= worked on the first try.

If you are debugging this: a Request body is a stream, so you cannot try json() and then fall back to text(). The second read fails no matter what the platform did. Read once, and design your endpoint so the query string is the path you trust.

4. `browser.evaluate()` returns a wrapped value

My first live call returned an object with no title in it, and the code fell over with Cannot read properties of undefined. The browser had worked fine; the return value simply is not the raw result of your script. It arrives inside a wrapper.

Rather than guess the wrapper's key name from a crash, I made the failure teach me: unwrap the likely candidates, and if none fit, throw an error containing the keys that actually arrived. One failed request then tells you the real shape instead of ten.

5. Two domains, and only one of them is your site

A deployment gets <project>-<deploymentId>.edgeone.dev. Your project also has <project>.edgeone.dev.

The first is pinned to one specific deployment forever. If you copy it out of the console and keep refreshing it after a push, you will watch a build succeed and conclude that your new code never landed. The production alias is the second one. Test there.

6. Node 24 is accepted, and routing is automatic

{"nodeVersion": "24"} in edgeone.json works, and no full version string is needed. Builds took about 73 seconds consistently. And a folder at agents/audit/ is served at /audit with no routing configuration at all, which is genuinely pleasant.

7. Export both handler names

The agents documentation shows export default async function(context). The Pages Functions convention is export async function onRequest(context). I could not determine from the docs which one the agent runtime actually calls, so I exported both. It costs one line and removes the guess entirely.

8. Your free subdomain has a reputation you did not earn

This one surprised me most, and it has nothing to do with code.

Every project gets a *.edgeone.dev subdomain. It works, it has SSL, it is free. But it is also shared with thousands of other deployments, and platforms like this are a favourite of phishing campaigns, so the whole namespace carries their history.

When I tried to post my project link on X, the post was refused outright: "this link has been identified by X or our partners as being potentially harmful." My site was a day old and had never done anything. It didn't matter. I was borrowing a neighbourhood's reputation, not building my own.

If you plan to share what you build, and for a hackathon or a portfolio that is the whole point, attach a custom domain early, under a name you already own. Every platform that hands you a free shared subdomain has this same property; it is simply not something anyone mentions while you are enjoying how fast the deploy was.

One more, from moving the repo

After launch I moved the project to a clean repository. Project Settings → Git Management → Disconnect, then connect the new repo. Changing the source repository does not rename the project, so the production URL survives, which matters if you have already published the link anywhere. Connecting also does not trigger a build; you have to deploy. Mine landed in about 70 seconds and the agent came back up with it.

What I'd tell someone starting

The browser sandbox is the reason to be here. It is not a gimmick. It lets an agent observe things about a page that no amount of fetch will reveal, and it is available on the free tier.

The rough edges are all discovery problems, not capability problems. Every one of the eight above is a five-minute fix once you know it exists, and a lost afternoon before that. Write your first deploy off as reconnaissance, log aggressively, and make your error messages report what actually arrived rather than what you expected. The evaluate() wrapper cost me one request to solve instead of ten purely because the error printed the keys it actually received.

If you are early in your career and wondering whether a platform like this is worth the trouble: the trouble is the material. I got a working tool out of this weekend, but I also got an article, and the article came entirely from the parts that went wrong.

One last thing I did not expect from the data. Both github.com and developer.mozilla.org score 90 on security headers rather than 100, and both lose those points to the same missing header: Permissions-Policy. When two of the most carefully operated sites on the web have the same gap, it is probably not negligence. It is a header the industry has not made a habit of yet.

Written for DevHandal 2026 Batch 2. #TencentEdgeOne #EdgeOneMakers #CODEPOLITAN #EdgeOne

DEV Community: Ravi Arnan Irianto