Tencent Cloud EdgeOne + COS Deployment Guide

This document consolidates two common deployment patterns:

1. API Acceleration: The client terminates TLS at the EdgeOne edge node, and EdgeOne origin-fetches via HTTPS to a load balancer or origin server.
2. Static Site: Build artifacts are uploaded to COS, and EdgeOne provides a custom domain, HTTPS, caching, and cache invalidation capabilities.

All examples use placeholders and do not include real account IDs, domains, buckets, zones, load balancers, or credentials. In production, SecretId, SecretKey, and temporary tokens should be sourced from environment variables, Key Management Services (KMS), or CI Secret Stores, and must not be written to repositories or public documentation.

1. Variables and Security Boundaries

Subsequent commands uniformly use environment variables:

export TENCENTCLOUD_SECRET_ID='<secret-id>'
export TENCENTCLOUD_SECRET_KEY='<secret-key>'

export EO_ZONE_ID='<edgeone-zone-id>'
export API_DOMAIN='api.example.com'
export STATIC_DOMAIN='www.example.com'
export ORIGIN_DOMAIN='origin.example.internal'

export COS_BUCKET='example-web-<appid>'
export COS_REGION='ap-guangzhou'

Security principles:

• Management accounts are used only for creating infrastructure; deployment pipelines use independent sub-accounts or short-lived credentials.
• IAM/CAM policies are authorized based on specific buckets and necessary actions, avoiding account-level cos:* permissions.
• SecretKey or fully signed request headers must not be printed in logs, shell history, or CI outputs.
• Public documentation displays only placeholders; real resource lists should be stored in private operations systems.

2. Pattern A: EdgeOne HTTPS Origin Fetch for API

The recommended order is "origin fetch first, then certificate, then DNS". This allows verification before switching production traffic, avoiding 5xx errors caused by undeployed certificates or mismatched origin Host headers.

2.1 Create Acceleration Domain

tccli teo CreateAccelerationDomain \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --DomainName "$API_DOMAIN" \
  --OriginInfo '{"OriginType":"IP_DOMAIN","Origin":"'"$ORIGIN_DOMAIN"'","PrivateAccess":"off"}' \
  --OriginProtocol HTTPS \
  --HttpsOriginPort 443

Verify the following configurations:

• The origin certificate covers ORIGIN_DOMAIN, the certificate chain is complete, and the certificate is not expired.
• The origin fetch Host matches the Layer 7 routing rules of the load balancer.
• Origin port 443 allows origin fetches from EdgeOne, and management ports are not inadvertently exposed.
• HTTP to HTTPS redirection is handled at the expected layer to avoid origin fetch redirect loops.

2.2 Deploy Edge Certificate

tccli teo ModifyHostsCertificate \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --Hosts '["'"$API_DOMAIN"'"]' \
  --Mode eofreecert

Poll the domain and certificate status to confirm both are ready before changing DNS:

tccli teo DescribeAccelerationDomains \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID"

2.3 Pre-switch Verification

First, resolve the access domain assigned by EdgeOne. Use curl --resolve to direct requests to the edge node while preserving the correct SNI and Host:

EO_CNAME="${API_DOMAIN}.eo.dnse1.com"
EO_IP=$(dig +short "$EO_CNAME" A | awk '/^[0-9.]+$/ {print; exit}')

curl --fail --show-error --silent \
  --resolve "${API_DOMAIN}:443:${EO_IP}" \
  -o /dev/null \
  -w 'HTTP %{http_code} TLS %{ssl_verify_result}\n' \
  "https://${API_DOMAIN}/health"

Only when TLS verification returns 0, the health check returns the expected status, and there are no anomalies in origin fetch logs, should you CNAME the business domain to EdgeOne.

2.4 DNS Cutover

tccli dnspod ModifyRecord \
  --endpoint dnspod.tencentcloudapi.com \
  --Domain example.com \
  --RecordId '<record-id>' \
  --SubDomain api \
  --RecordType CNAME \
  --RecordLine Default \
  --Value "${API_DOMAIN}.eo.dnse1.com" \
  --TTL 600

Lower the TTL before the cutover; restore the standard TTL after stable operation. Keep the original record value to ensure a quick rollback in case of anomalies.

3. Pattern B: COS Static Site + EdgeOne

3.1 Prepare Bucket

Static website hosting typically requires:

• Creating a bucket in the specified region.
• Uploading index.html and static assets.
• Configuring the static website homepage and error pages.
• Deciding on public read, private origin fetch, or signed access based on business needs; do not mechanically grant write permissions to the entire bucket.

The COS static website endpoint usually looks like:

<bucket>.cos-website.<region>.myqcloud.com

3.2 Create Static Site Acceleration Domain

COS_WEBSITE_ENDPOINT="${COS_BUCKET}.cos-website.${COS_REGION}.myqcloud.com"

tccli teo CreateAccelerationDomain \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --DomainName "$STATIC_DOMAIN" \
  --OriginInfo '{"OriginType":"COS","Origin":"'"$COS_WEBSITE_ENDPOINT"'","PrivateAccess":"off"}' \
  --OriginProtocol FOLLOW \
  --HttpOriginPort 80 \
  --HttpsOriginPort 443

When OriginType=COS, do not additionally set HostHeader; the platform handles this based on the COS origin type. Subsequently, deploy the edge certificate, pre-verify, and switch DNS following the order in Pattern A.

3.3 Upload and Cache Purging

coscli sync ./dist "cos://${COS_BUCKET}/" \
  --region "$COS_REGION" \
  --delete

tccli teo CreatePurgeTask \
  --region ap-guangzhou \
  --endpoint teo.tencentcloudapi.com \
  --ZoneId "$EO_ZONE_ID" \
  --Type purge_host \
  --Targets '["'"$STATIC_DOMAIN"'"]'

--delete will delete extra objects in the target endpoint; use it only when the build directory and target bucket prefix have been confirmed. If the release process cannot guarantee this, use immutable filenames and upload only new resources.

4. Least Privilege

The deployment account should only be granted permissions necessary for the target bucket and cache purging. The following is a structural illustration, not a complete policy ready for direct use:

{
  "version": "2.0",
  "statement": [
    {
      "effect": "allow",
      "action": [
        "cos:PutObject",
        "cos:DeleteObject",
        "cos:GetObject",
        "cos:GetBucket"
      ],
      "resource": [
        "qcs::cos:<region>:uid/<appid>:<bucket>/*"
      ]
    },
    {
      "effect": "allow",
      "action": ["teo:CreatePurgeTask"],
      "resource": ["<edgeone-resource-scope>"]
    }
  ]
}

Actual action names and resource formats should be based on the current Tencent Cloud CAM documentation and API responses. Before going live, verify with an independent test account that it "can publish but cannot manage other buckets".

5. Go-Live Checklist

• EdgeOne domain status is normal.
• Edge certificate covers the business domain, with a valid certificate chain and expiration date.
• API origin fetch uses HTTPS, with correct origin certificate and Host routing.
• curl --resolve pre-verification passed.
• Original DNS values are recorded for rollback in case of failure.
• Static assets use content hashing or explicit cache versioning strategies.
• HTML cache duration is shorter than that of hashed JS/CSS/images.
• Deployment account has minimal permissions for target resources only.
• No real keys or account-level resource lists in logs, scripts, or documentation.

6. Common Issues

7. Rollback

In case of certificate, origin fetch, or cache anomalies:

1. Restore DNS to the pre-cutover record.
2. Verify that the origin is directly accessible.
3. Keep EdgeOne configurations for offline troubleshooting; do not continuously stack changes during an incident.
4. After fixing the issue, pre-verify again with curl --resolve before proceeding with the next cutover.

Separating certificate deployment, pre-verification, DNS cutover, and rollback is far more reliable than "changing DNS immediately after creating the domain".