Unleash Edge on AliCloud — Serverless, Edge Computing & Deployment Options

⚠ Critical: "Edge" in the Name Does NOT Mean Edge Computing

The Naming Trap

"Unleash Edge" is named "Edge" because it sits at the edge of your infrastructure — the boundary between your application services and the Unleash feature flag server. It is not an edge computing product. It does not run in Cloudflare Workers, Lambda@Edge, AliCloud CDN Edge Script, or any WebAssembly edge runtime.

Think of it like a database connection pool (PgBouncer) — it lives inside your cluster, close to your apps, and caches data so apps don't hit the main server directly. Nobody would deploy PgBouncer to a CDN edge node.

❌ What "Edge" does NOT mean here:

• CDN edge nodes (Cloudflare, Fastly, AliCloud CDN)
• Serverless functions (Lambda, Function Compute FC)
• WebAssembly runtimes (Cloudflare Workers, Deno Deploy)
• AliCloud Edge Script or EdgeRoutine
• Low-power IoT edge devices

✓ What Unleash Edge actually is:

• A long-running Rust process (stateful)
• Keeps flags in memory (persistent cache)
• Maintains a persistent TCP/SSE connection upstream
• Deployed inside your cluster, close to your app services
• Needs a container runtime, NOT a function runtime

1. What Unleash Edge Actually Requires to Run

Understanding these requirements tells you immediately which platforms work and which don't.

MUST HAVE

🔄 Persistent Process

Edge is a long-running daemon. Serverless functions are killed after each invocation — cache is lost.

MUST HAVE

🧠 In-Memory State

Flags are stored in a HashMap in RAM. No external cache (Redis etc) is used — Edge IS the cache.

MUST HAVE

📡 Outbound TCP

Persistent SSE or HTTP/2 connection to upstream Unleash. Cannot work with request-scoped networking.

MUST HAVE

🐳 Container Runtime

Runs as a Docker container or Rust binary. Not a WebAssembly module. Needs full Linux syscalls.

NICE TO HAVE

💾 Disk (optional)

For bootstrap file (offline mode). Memory-only works fine for online Edge mode.

NICE TO HAVE

🔁 Rolling Restarts

Graceful pod replacement without dropping flag requests. K8s handles this automatically.

The fatal constraint for serverless: Serverless functions have no persistent memory between invocations. Every request would cold-start a new Edge process with an empty cache, then spend 100–500ms fetching flags from upstream — defeating the entire purpose of Edge (which is to avoid that round trip).

2. Serverless — Why It Doesn't Work

3. Alibaba Cloud Services — Overview

✅

ACK

Alibaba Cloud K8s

Container Service for Kubernetes. Full K8s — same as deploying anywhere. Best option. Full StatefulSet / Deployment / DaemonSet support.

✅

SAE

Serverless App Engine

Serverless for containers (not functions). Runs long-lived container processes. You deploy a Docker image — SAE manages the infrastructure. Works with Edge.

✅

ECI

Elastic Container Instance

Serverless containers on AliCloud. Like AWS Fargate. Runs a Docker container persistently. Supports health checks and long-running processes. Works with Edge.

⚠️

ENS

Edge Node Service

AliCloud's actual edge computing nodes (distributed PoPs). Supports containers. Edge can run here — but understand latency tradeoffs and networking constraints.

❌

Function Compute (FC)

Serverless functions

AliCloud's Lambda equivalent. Functions only — no persistent process, no persistent memory. Cannot run Unleash Edge.

❌

CDN Edge Script

JS at CDN PoPs

Runs JavaScript at AliCloud CDN edge nodes. Limited JS environment, no TCP, no Docker. Cannot run Unleash Edge.

4. ACK — Container Service for Kubernetes ✅ (Recommended)

Best choice for Unleash Edge on AliCloud. ACK is managed Kubernetes — deploy Edge exactly like you would on AWS EKS or GKE. All K8s manifests from the main study page work as-is.

What you get

✓

Deployment + Service + HPA

Deploy Edge as a 2-replica Deployment behind a ClusterIP Service. Apps use unleash-edge.unleash.svc.cluster.local:3063.

✓

Multi-zone spread

ACK supports topology.kubernetes.io/zone labels. Use topologySpreadConstraints to spread Edge pods across AliCloud availability zones.

✓

ARMS / Prometheus integration

AliCloud ARMS (Application Real-Time Monitoring) can scrape Edge's /internal-backstage/prometheus endpoint natively.

# Deploy Edge on ACK (same as standard K8s)
kubectl create namespace unleash

kubectl create secret generic unleash-edge-token \
  -n unleash \
  --from-literal=token="*:*.your-edge-token"

# Apply standard Deployment manifest
kubectl apply -f unleash-edge-deployment.yaml -n unleash

# ACK-specific: use SLB (Server Load Balancer)
# for external access if apps are outside the cluster
apiVersion: v1
kind: Service
metadata:
  annotations:
    # AliCloud SLB annotation for internal LB
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: intranet
spec:
  type: LoadBalancer
      

5. SAE — Serverless App Engine ✅ (Good for simplicity)

Important distinction: SAE is "serverless" in that you don't manage servers — but it runs long-lived container processes, not functions. It's AliCloud's equivalent of Google Cloud Run or AWS App Runner. A long-running Rust process like Unleash Edge is exactly what SAE is designed for.

SAE advantages for Edge

No K8s cluster to manage

SAE handles the underlying infrastructure. You just deploy a Docker image and SAE runs it persistently.

Per-second billing

Pay for actual CPU/RAM used. Edge is extremely lightweight (Rust, ~30MB RAM) — very low cost on SAE.

Health checks built-in

SAE supports HTTP liveness and readiness probes — configure them to hit /health and /ready.

−

No DaemonSet or sidecar

SAE doesn't support K8s primitives. You run Edge as a standalone SAE app — apps call it via Service Discovery or internal domain.

# SAE deployment via Alibaba Cloud CLI
aliyun sae CreateApplication \
  --AppName      unleash-edge \
  --NamespaceId  cn-hangzhou:your-ns-id \
  --ImageUrl     registry.cn-hangzhou.aliyuncs.com/your/unleash-edge:latest \
  --Cpu          500 \
  --Memory       256 \
  --Replicas     2 \
  --Command      "edge" \
  --Envs         '[{"name":"UPSTREAM_URL","value":"http://unleash:4242"},{"name":"PORT","value":"3063"}]' \
  --Liveness    '{"exec":null,"httpGet":{"path":"/health","port":3063}}' \
  --Readiness   '{"exec":null,"httpGet":{"path":"/ready","port":3063}}'

# SAE auto-registers with MSE Service Discovery
# Other SAE apps call Edge via: unleash-edge.your-ns.internal:3063
      

6. ECI — Elastic Container Instance ✅ (Fargate-like)

ECI is AliCloud's serverless container service — like AWS Fargate. You run a container image without managing nodes. Perfect for running Edge as a simple container without a full K8s cluster. Can be used standalone or as the backend for ACK virtual nodes.

🐳

Direct Container Run

No VM, no K8s

Create an ECI instance with unleashorg/unleash-edge:latest. ECI runs it as a persistent container. Accessible via VPC internal IP.

⚡

ACK Virtual Node

ECI behind K8s

If you have ACK, add a virtual node backed by ECI. Deploy Edge pods on the virtual node — no dedicated ECS nodes needed for Edge.

💡

Best For

Small teams, low ops

You want to run Edge but don't have (or don't want) a K8s cluster. ECI gives you a managed container runtime for just the Edge process.

# Create ECI group for Unleash Edge
aliyun eci CreateContainerGroup \
  --ContainerGroupName  unleash-edge \
  --RegionId            cn-hangzhou \
  --VSwitchId           vsw-xxx \
  --SecurityGroupId     sg-xxx \
  --Containers.1.Name               edge \
  --Containers.1.Image              unleashorg/unleash-edge:latest \
  --Containers.1.Cpu                0.5 \
  --Containers.1.Memory             0.5 \
  --Containers.1.Command.1          edge \
  --Containers.1.EnvironmentVars.1.Key    UPSTREAM_URL \
  --Containers.1.EnvironmentVars.1.Value  http://unleash-server:4242 \
  --Containers.1.Ports.1.Port        3063 \
  --Containers.1.Ports.1.Protocol    TCP \
  --Containers.1.LivenessProbe.HttpGet.Path  /health \
  --Containers.1.ReadinessProbe.HttpGet.Path /ready
  

7. ENS — Edge Node Service ⚠️ (True Edge Nodes, But Tradeoffs)

ENS is AliCloud's actual edge computing infrastructure — physical nodes distributed across 2800+ locations in China and globally. You can run Unleash Edge here, but you need to understand the tradeoffs carefully.

What ENS provides

📍

Distributed PoPs across China

ENS nodes in 300+ cities. If your users are in Shenzhen, your Edge can run in Shenzhen — flag reads are local.

🐳

Supports Docker containers

ENS supports container workloads — you can deploy unleashorg/unleash-edge:latest on an ENS node.

🔗

Persistent processes allowed

Unlike CDN edge functions, ENS runs full VMs/containers. Persistent process + in-memory cache + SSE connections all work.

ENS tradeoffs for Edge

⚠

Higher operational complexity

ENS nodes need manual management. No native K8s — you deploy as standalone containers or VMs with your own orchestration.

⚠

Upstream connectivity varies

ENS nodes at distant PoPs may have higher latency to your Unleash server (in a central region). ENS → Unleash sync lag increases.

⚠

Use case is niche

Only makes sense if your apps are deployed on ENS too (e.g., CDN-adjacent processing). For standard K8s apps, ACK Edge is better.

When ENS makes sense: You have services running on ENS (e.g., video processing close to users, IoT data aggregation) and those services need feature flags. Deploy Unleash Edge on the same ENS node as your service — sub-millisecond flag reads. Use Edge chaining: ENS Edge → Central Edge (ACK) → Unleash Server.

8. Function Compute ❌ — Cannot Run Unleash Edge

AliCloud Function Compute (FC) is a serverless functions platform (like AWS Lambda). Despite being able to run custom runtimes and containers, it is fundamentally incompatible with Unleash Edge for these reasons:

💀

No Persistent State

Fatal constraint

FC instances are frozen or killed between requests. Edge's in-memory flag cache is destroyed every invocation. Every call would need to re-fetch flags from Unleash — 200ms+ latency instead of <1ms.

💀

No SSE / Long Connections

Fatal constraint

Function Compute has a maximum execution timeout (even async has limits). A persistent SSE connection to Unleash upstream is impossible — FC would kill it.

💀

Concurrent Scale-Out

Makes it worse

Under load, FC spins up many instances. Each instance has its own empty cache and its own upstream connection to Unleash — thundering herd problem, defeating Edge's purpose entirely.

🤔

Workaround: FC calls Edge

Use both together

If your app IS a Function Compute function, point your Unleash SDK at an Edge instance running in ACK/SAE/ECI. FC functions call Edge (fast internal call), Edge handles caching and upstream sync.

// AliCloud Function Compute: call Edge, don't run Edge
// Your FC function:
const { initialize } = require('unleash-client');

// Initialize SDK once at cold start (stays warm between invocations)
// Point to Edge running in VPC (ACK/SAE/ECI) — NOT to Unleash server directly
const unleash = initialize({
  url: 'http://unleash-edge.internal.vpc:3063/api',  // Edge via VPC internal DNS
  appName: 'my-fc-function',
  customHeaders: { Authorization: process.env.UNLEASH_CLIENT_TOKEN }
});

module.exports.handler = async (event, context) => {
  const flagEnabled = unleash.isEnabled('new-algo');
  // SDK fetches from Edge (same VPC, <1ms) after warm-up
};
  

Note on FC warm instances: If a FC instance stays warm between requests, the SDK's in-memory cache persists for that instance. But you cannot guarantee warmth, and each parallel invocation gets its own cold instance. Edge in the VPC is the stable cache that all FC instances share.

9. Recommended Setup for AliCloud

🏆

Option A — ACK (best, full K8s)

You already have ACK → deploy Edge as a Deployment with 2 replicas in the unleash namespace. All other pods in the cluster call Edge via unleash-edge.unleash.svc:3063. Use ARMS for metrics.

🥈

Option B — SAE (no K8s ops, still great)

You use SAE for your apps → deploy Edge as a SAE application (2 instances). Apps discover Edge via SAE's built-in MSE service discovery or a fixed internal domain.

🥉

Option C — ECI (minimal, standalone)

Simplest: create an ECI group with 2 Edge containers in your VPC. Apps call the ECI internal IP. Use an internal SLB in front of the 2 ECI instances for HA.

🌏

Option D — ACK + ENS Edge Chaining (multi-region)

Central Edge in ACK (Beijing/Hangzhou) → Regional Edge on ENS nodes (Shenzhen, Shanghai, Chengdu). Apps at each location call local ENS Edge. Flags propagate from central to edge within 15–30s.

10. Full AliCloud Architecture Diagram

11. AliCloud Options — Side-by-Side

AliCloud Service	Can Run Edge?	K8s Support	Persistent Process	Ops Complexity	Cost	Best For
ACK	✓ Yes	Full K8s	Yes	Medium	Node cost	Teams already on K8s
SAE	✓ Yes	No (managed)	Yes	Low	Pay per use	Teams wanting no K8s ops
ECI	✓ Yes	Via virtual node	Yes	Low	Per-second billing	Minimal footprint, standalone
ENS	⚠ Technically yes	Limited	Yes	High	Per-node	Apps deployed on ENS edge nodes
Function Compute	✗ No	No	No	—	—	FC functions should CALL Edge, not run it
CDN Edge Script	✗ No	No	No	—	—	Cannot run Rust containers

12. If You Need True Edge Computing — Alternative Approach

Scenario: Your app runs in Cloudflare Workers / AliCloud CDN Edge Script / other WebAssembly edge runtime, and you need feature flags at the CDN layer. Unleash Edge cannot run there. Here are your options:

🌐

Call Edge from CDN Worker

Recommended

CDN worker makes a subrequest to your Edge instance (ACK/SAE in VPC behind an internal endpoint). Flag result is fetched per-request from Edge. Adds ~10–50ms depending on proximity.

📦

Bake flags into CDN deployment

Static approach

Use Unleash's export API to dump flag values at build/deploy time. Bake them into your CDN worker bundle as a JSON constant. Update = redeploy worker. Works for stable flags.

🔄

KV Store caching

Cloudflare / AliCloud approach

A background process (cron) periodically fetches flags from Edge/Unleash and writes them to the CDN's KV store (Cloudflare KV, AliCloud DCDN EdgeKV). Workers read from KV — fast, no origin call.

⚙️

Unleash Server CDN caching

Header-based

Cache the /api/frontend response at the CDN layer with a short TTL (e.g. 30s). All CDN PoPs share the same cached flag response. Simple but context-aware evaluation is lost.

// AliCloud CDN EdgeScript / Worker calling Edge in VPC
// (pattern: CDN worker → Edge → Unleash)

async function getFlags(userId) {
  // Call Edge via VPC-accessible endpoint (internal SLB or API GW)
  const resp = await fetch('https://unleash-edge-internal.example.com/api/frontend', {
    headers: {
      'Authorization': FRONTEND_TOKEN,
      'Content-Type': 'application/json'
    },
    // POST with context for server-side evaluation
    method: 'GET',
  });
  return resp.json();  // { toggles: [{name, enabled}] }
}

// Or: read from AliCloud DCDN EdgeKV (pre-populated by cron):
const flags = JSON.parse(await edgeKV.get('unleash-flags'));
const enabled = flags.toggles.find(t => t.name === 'new-feature')?.enabled;
  

Bottom line for AliCloud users:
Run Unleash Edge in ACK or SAE (inside your VPC). All services — whether they're ACK pods, SAE apps, ECI containers, or Function Compute functions — call Edge over the VPC network. Only if you're building CDN-layer logic (EdgeScript/Deno) do you need the KV or subrequest pattern above. The name "Edge" is just a name — treat it as a fast, in-cluster feature flag cache.