Skip to main content

Hosting a Static Site on Aliyun OSS

If your site is essentially just HTML + CSS + JS + images, OSS is often less work than maintaining a cloud server. This guide answers the most common questions: what OSS can host, when you need ICP filing, how to bind a root domain, and whether you can shut down your existing server.

Bottom Line​

  • Pure static sites can be hosted directly on OSS. Common scenarios include documentation sites, blog static exports, portfolios, and landing pages.
  • If you are only hosting images, JS, CSS, fonts, and downloadable files, OSS is also a good fit. But databases, admin panels, server-side rendering, and scheduled tasks still need a separate compute service.
  • When the bucket is in mainland China and you use a custom domain for website access, the domain must meet ICP filing requirements.
  • When the bucket is in Hong Kong or other overseas regions, mainland China ICP filing is usually not required, but access experience from mainland China will generally be weaker than with a mainland bucket.
  • Accessing HTML directly through the default OSS bucket domain may trigger a download instead of rendering the page. For production use, bind a custom domain.
  • Whether you can retire your existing server depends not on whether pages load, but on whether your site truly has no backend dependencies.

What OSS Is Good For​

ScenarioSuitable for OSS?Notes
Documentation sites, blog static exports, portfoliosYesUpload build output directly
Images, JS, CSS, fonts, file downloadsYesClassic static asset hosting
Frontend of a separated frontend/backend projectYesFrontend on OSS, API still needs other services
WordPress, PHP, Java, Node backend appsNot for the whole siteStill needs a server or serverless compute
Image hosting or file distribution onlyYesWorks even better with a custom domain and CDN

If your project is a single-page application (SPA), it can also go on OSS. You just need to configure the homepage and routing fallback in single-page application mode.

How to Choose: Filing and Region​

Aliyun's rules for binding custom domains to OSS boil down to two points:

  • Mainland China bucket + custom domain for website or static resource access: the domain must meet filing requirements.
  • If the root domain is already filed, subdomains under that same root domain bound to OSS usually do not need a separate filing.

Use this table to guide your decision:

Bucket RegionMainland ICP Filing Required?Best ForTrade-offs
Mainland ChinaYesProduction sites targeting domestic usersBetter access experience, but requires filing process
Hong Kong / OverseasUsually notQuick launch without filing firstHigher latency from some regions

One common misconception: do not assume that "having OSS means you can file directly". Whether you qualify for filing and whether you have an available filing service code depends on the filing console and your account status.

Can You Bind a Root Domain Directly to OSS?​

Yes, but it involves two layers:

  1. From the OSS side, custom domain binding is supported.
  2. From the DNS side, whether a root domain (e.g. example.com) works depends on whether your DNS provider supports ALIAS or similar CNAME flattening.

The more reliable approach in practice:

  • Subdomains like www.example.com or static.example.com: set up a CNAME following the official docs.
  • Root domain example.com: first confirm whether your DNS provider supports ALIAS or equivalent.
  • If not, use www as the primary access address, redirect the root domain, or add a CDN/gateway layer in front of OSS.

In other words, whether the root domain works is not an OSS-only question. It is determined by both OSS binding capability and DNS resolution capability together.

A More Reliable Launch Process​

If you are migrating an existing static site to OSS, follow this order:

  1. Confirm the site is truly static output, or at least that the frontend can be deployed independently as static files.
  2. Generate build artifacts locally or in CI, e.g. dist, build, or the statically exported out directory.
  3. Create an OSS bucket and decide the region first: mainland China or Hong Kong/overseas.
  4. Upload static files.
  5. In the bucket's static website hosting settings, set the default homepage to index.html and configure an error page. For SPAs, configure in single-page application mode.
  6. Bind a custom domain and complete domain ownership verification.
  7. Add DNS records at your DNS provider. Typically CNAME; for root domains, check if ALIAS or equivalent is supported.
  8. Add HTTPS and CDN as needed.
  9. Test the homepage, static assets, deep-link routing, 404 page, and refresh behavior.

If you find that "visiting the bucket domain directly triggers an HTML download", do not assume the file is broken. This is normal default behavior for OSS. Production access should always go through the custom domain.

When Can You Retire the Existing Server?​

Use one sentence to decide: as long as page rendering does not depend on real-time server-side processing, you can potentially retire the server.

These cases usually allow you to stop paying for ECS:

  • Pure static sites like Docusaurus, VitePress, Hugo, Jekyll
  • React / Vue projects that produce static files after build
  • Frontend on OSS, backend API moved to other independent services

These cases mean you should NOT retire the server just because "the homepage loads":

  • Database-dependent sites like WordPress or Typecho
  • Projects still using SSR / API Routes like Next.js or Nuxt
  • Systems requiring login state, file upload processing, scheduled tasks, search index generation, or other server-side capabilities

So the more accurate statement is not "bind OSS and shut down the server", but "once the site has been fully static-ified, the server can potentially exit the main path".

Filing Does Not Expire Automatically, But Watch Out for These Issues​

Aliyun's official guidance states that a filing number itself has no fixed expiration date. As long as the information is accurate, changes are filed promptly, the access relationship is valid, and content is compliant, the filing can remain valid indefinitely.

The real risks to watch for:

  • You submit a deregistration request yourself.
  • The domain expires, gets deleted or transferred, and the new owner initiates related operations.
  • Filing information is inaccurate or contact details become invalid, leading to access cancellation.
  • After migrating from one provider to another, you fail to complete the new access filing in time.
  • Website content involves illegal or non-compliant material.

If your entity information, contact details, or site access relationship changes, the correct action is to file a change or new access filing promptly, not to leave it alone.

Decision Guide for Beginners​

If you just want to pick a path that is hard to get wrong:

  • Want more stable domestic access and willing to go through the filing process: choose a mainland China bucket.
  • Just launching temporarily, testing, or showcasing personally without filing first: choose a Hong Kong or overseas bucket.
  • Site is already pure static output: prioritize OSS.
  • Site still depends on databases, admin panels, or server-side logic: use OSS for static assets first, do not rush to retire the server.

References​