Skip to content
KubeEdge website and documentation repo:
Branch: master
Clone or download
Latest commit 298eece Apr 25, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
.github/ISSUE_TEMPLATE Update issue templates Feb 2, 2019
assets/css Made some style changes to the timeline widget. Removed some content. Mar 6, 2019
config/_default Added DisQus comments support for blogs. Apr 22, 2019
content add contest blog in chinese (#41) Apr 25, 2019
layouts [New Feature]Added talks section and first talk. Mar 15, 2019
resources/_gen Changed the theme. Multilingual support enabled. Jan 29, 2019
static/img Added a homepage banner to win KubeCon Shanghai tickets Apr 16, 2019
themes/academic [New Feature]Added talks section and first talk. Mar 15, 2019
.gitignore Changed the theme. Multilingual support enabled. Jan 29, 2019 Updated the code of conduct doc Feb 2, 2019 fix and Nov 8, 2018
LICENSE Create Feb 2, 2019 Update Mar 29, 2019
netlify.toml Changed the theme. Multilingual support enabled. Jan 29, 2019

Creating and updating the KubeEdge docs

Welcome to the GitHub repository for KubeEdge's public website. The docs are hosted at

We use Hugo to format and generate our website, and Netlify to manage the deployment of the site. Hugo is an open-source static site generator that provides us with templates, content organisation in a standard directory structure, and a website generation engine. You write the pages in Markdown, and Hugo wraps them up into a website.


Here's a quick guide to updating the docs. It assumes you're familiar with the GitHub workflow and you're happy to use the automated preview of your doc updates:

  1. Fork the KubeEdge/website repo on GitHub.
  2. Make your changes and send a pull request (PR).
  3. If you're not yet ready for a review, add a comment to the PR saying it's a work in progress or add [WIP] in your PRs title. You can also add /hold in a comment to mark the PR as not ready for merge. (Don't add the Hugo declarative "draft = true" to the page front matter, because that will prevent the auto-deployment of the content preview described in the next point.)
  4. Wait for the automated PR workflow to do some checks. When it's ready, you should see a comment like this: deploy/netlify — Deploy preview ready!
  5. Click Details to the right of "Deploy preview ready" to see a preview of your updates.
  6. Continue updating your doc until you're happy with it.
  7. When you're ready for a review, add a comment to the PR and assign a reviewer/approver. See the Kubeedge contributor guide.

Previewing your changes on a local website server

If you'd like to preview your doc updates as you work, you can install Hugo and run a local server. This section shows you how.

Install Hugo

See the Hugo installation guide. Here are some examples:

Mac OS X:

brew install hugo


  1. Download the latest Debian package from the Hugo website. For example, hugo_0.54_Linux-64bit.deb.

  2. Install the package using dpkg:

    sudo dpkg -i hugo_0.46_Linux-64bit.deb
  3. Verify your installation:

    hugo version

Run a local website server

Follow the usual GitHub workflow to fork the repo on GitHub and clone it to your local machine, then use your local repo as input to your Hugo web server:

  1. Ensure you are in your target branch:

    git branch
  2. Start your website server. Make sure you run this command from the /website/ directory, so that Hugo can find the config files it needs:

    hugo server -D
  3. Your website is at http://localhost:1313/.

  4. Continue with the usual GitHub workflow to edit files, commit them, push the changes up to your fork, and create a pull request. (See the GitHub workflow

  5. While making the changes, you can preview them on your local version of the website at http://localhost:1313/. Note that if you have more than one local git branch, when you switch between git branches the local website reflects the files in the current branch.

Useful Hugo docs:


For each stable release, we should create a new branch for the relevant documentation. For example, the documentation for the v0.1 stable release are maintained in the v0.1-branch. Each branch has a corresponding netlify website that automatically syncs each merged PR.

Going forward, the versioned sites should follow this convention:

  • always points to the current master branch
  • always points to Github head
  • points to the release at vXXX.YYY-branch
You can’t perform that action at this time.