DEV Community

Cover image for A Technical Review of Tencent EdgeOne Makers
Bayu Erich
Bayu Erich

Posted on Edited on

A Technical Review of Tencent EdgeOne Makers

I came across Tencent EdgeOne Makers through the DevHandal 2026 Batch 2 program, a collaboration between CODEPOLITAN and Tencent EdgeOne. Most of my deployments so far have been on shared hosting or a VPS, so the pitch caught my attention: full-stack hosting, serverless functions, and native AI support running on a global edge network. Instead of just reading about it, I migrated a real project. This review is based on what that migration actually looked like.

What it is

EdgeOne Makers is a web and agent development and deployment platform built on Tencent EdgeOne infrastructure. It is the renamed, upgraded version of EdgeOne Pages. The old product logic and features stay the same, but the platform now adds native support for AI agents on top of the full-stack web capabilities.

It covers three things: frontend pages (static sites and SPAs), dynamic APIs via serverless functions at the edge or in the cloud, and AI agents with a runtime, sandbox, conversational memory, and model gateway.

Strengths

The deployment pipeline is modern. You can connect a Git repository, use the CLI, the MCP server, or an IDE plugin, and deployment becomes automated. Continuous delivery from a GitHub Actions workflow is supported out of the box.

Speed is the other big draw. Static assets and dynamic responses both go through the EdgeOne global edge network with caching, and it shows in load times.

The serverless functions are the low-effort part. You skip server maintenance and capacity planning entirely, and scaling happens on its own based on workload.

Framework support is the most pleasant surprise. Next.js, Nuxt, Astro, SvelteKit, React Router, Vite, React, Vue. The platform detects the framework and builds it without a config file on your end.

What I deployed: a full-stack app with Node.js Cloud Functions

The real test was migrating gitSdm, my GitHub repository visualizer. The frontend is a React SPA built with Vite, and the backend is a Node.js server exposing roughly 20 API endpoints: repository analysis, dependency graphs, file tree exploration, AI-powered summaries, and more. Previously it ran on a VPS. I moved it to EdgeOne Makers Cloud Functions.

Handler mode and file-system routing

Cloud Functions on EdgeOne Makers support two development modes. Handler mode is pure serverless: each file under cloud-functions/api/ becomes a route, and the file name determines the URL path. cloud-functions/api/users/list.js maps to /api/users/list. Dynamic routing works too — [id].js matches one path segment, and [[default]].js is a catch-all matching everything under its prefix.

This is the cleanest part of the developer experience: no framework needed, no server setup, and the file tree is the routing table. A handler is just a function:

// cloud-functions/api/hello.js
export default function onRequest(context) {
  return new Response('Hello from Node.js!', {
    headers: { 'Content-Type': 'text/plain' },
  });
}
Enter fullscreen mode Exit fullscreen mode

The context object gives you params, env, clientIp, geo data, and the request. Handlers return a standard Response object.

How I structured the migration

The backend had ~20 endpoints, so instead of 20 loose handler files, I kept the whole server as one bundled entry. The build produced cloud-functions/api/[[default]].js — a thin handler that delegates every /api/* request to a bundled bundle.js, which is treated by the platform as an auxiliary module (imported by the entry, not registered as its own route). One file, one catch-all, the entire Node.js server behind it.

For the SPA fallback, an edgeone.json rewrite rule sends unmatched paths to /index.html. Environment variables (the AI provider key) come from the platform's env, merged into process.env at runtime. For long-running analysis calls, I set cloudFunctions.maxDuration: 120 — Cloud Functions allow up to 120 seconds, which the default 30 would have been too short for.

A build quirk worth knowing

The most interesting lesson came from the platform's build tool. It mangles string literals that contain code-like patterns. My first deploy failed with Unterminated string literal at a line that looked completely innocent in source:

if (line.trim().startsWith("export {")) { /* ... */ }
Enter fullscreen mode Exit fullscreen mode

The string "export {" contains an unbalanced opening brace, and the build tool's parser choked on it. The fix was to construct the brace at runtime: String.fromCharCode(123) instead of a literal {.

The second failure was sneakier. My mock-data file used template literals containing sample source code (an example src/main.tsx with import './index.css';). The build tool interpreted that import inside the string as a real module import and failed with Could not resolve "./index.css". Re-encoding the mock contents as a base64 string fixed it — base64 contains no quotes, backticks, or braces, so the parser leaves it alone.

Two practical takeaways: when deploying to EdgeOne Makers, audit your string literals for unbalanced braces, quotes, backticks, or anything that looks like an import/export statement, and prefer base64 or runtime character construction for code-shaped strings.

Local debugging with the CLI

edgeone makers dev runs the same build tool locally, which is how I caught both issues above before deploying. The CLI also handles project creation and deployment; for Git-connected projects, pushing to the repository triggers an auto-build and release. For one-off tests, direct folder upload worked just as well.

The result

After fixing the string literal issues, the migration was painless. The frontend builds with the framework detection, the Cloud Function registered under /api/*, and the live site is running at gitsdm.edgeone.dev — HTTPS, global edge delivery, and the Node.js backend responding in the same deployment. Static assets and API responses share one project, one domain, and one deployment pipeline.

Live API response from gitsdm.edgeone.dev/api/config

gitSdm live on gitsdm.edgeone.dev

Makers Models

The AI features in gitSdm (repository summaries and analysis) run on Makers Models, EdgeOne Makers' unified model access service. Instead of wiring a provider SDK per vendor, the backend talks to one endpoint, https://ai-gateway.edgeone.link/v1, with a single API key from the platform. The provider key never touches my code — only the gateway key does.

The endpoint is compatible with the OpenAI SDK, the Anthropic SDK, and the Vercel AI SDK, plus plain HTTP clients. In gitSdm the backend uses the OpenAI-compatible interface with MAKERS_MODELS_KEY and a model id like @makers/deepseek-v4-flash:

import OpenAI from 'openai';

const client = new OpenAI({
  apiKey: process.env.MAKERS_MODELS_KEY,
  baseURL: 'https://ai-gateway.edgeone.link/v1',
});

const completion = await client.chat.completions.create({
  model: '@makers/deepseek-v4-flash',
  messages: [{ role: 'user', content: 'Summarize this repository' }],
});
Enter fullscreen mode Exit fullscreen mode

To switch models you change the model parameter — no code changes. Provider keys are encrypted and hosted by the platform, and there are built-in models that work without binding your own keys. Supported providers include OpenAI, Anthropic, Google AI Studio, DeepSeek, MiniMax, Zhipu, Hunyuan and MoonShot AI.

Makers Models provider and model list in the EdgeOne console

Storage and observability

The platform also has KV and Blob storage for persistence, metric and log analysis, custom domains with free SSL certificates, custom 404 pages, and cache configuration. The Makers console provides basic log viewing for function calls, which helps trace API exceptions quickly.

Verdict

After migrating a real full-stack application with a Node.js backend, the picture is clearer than a spec sheet would be. The file-system routing made the backend migration straightforward, the single-bundle catch-all pattern kept 20 endpoints under one entry, and the auto-build pipeline shipped everything — frontend and functions — as one unit.

A few caveats. The platform is still marked Beta. Pricing depends on usage, so check the pricing page before committing. And the build tool's handling of code-shaped string literals is a genuine footgun — budget some time for it if your backend carries embedded code samples or templates.

For developers who want to pick up edge computing and serverless while shipping real projects, EdgeOne Makers is worth trying. It made a full-stack migration feel small, and that is the whole point. You can start on the free plan.

Top comments (0)