kubevela · FogDong · Sep 16, 2025 · Sep 11, 2025 · Sep 11, 2025 · Sep 11, 2025
diff --git a/blog/2021-10-08-blog-1.1.md b/blog/2021-10-08-blog-1.1.md
@@ -23,7 +23,7 @@ Kubernetes has made it easy to build application deployment infrastructure, eith
 
 The latest DORA survey [1] shows that organizations adopting continuous delivery are more likely to have processes that are more high quality, low-risk, and cost-effective. Though the question is how we can make it more focused and easy to practice. Hence, KubeVela introduces Open Application Model (OAM), a higher level abstraction for modeling application delivery workflow with app-centric, consistent and declarative approach. This empowers developers to continuously verify and deploy their applications with confidence, standing on the shoulders of Kubernetes control theory, GitOps, IaC and beyond.
 
-![](https://static.kubevela.net/images/cicd.png) 
+![](https://kubevela.io/images/cicd.png) 
 
 KubeVela latest 1.1 release is a major milestone bringing more continuous delivery features. It highlights:
 
@@ -70,7 +70,7 @@ KubeVela 1.1 introduces multi-environment, multi-cluster rollout. It integrates
 
 Below is a demo for a multi-stage application rollout from Staging to Production. The local cluster serves as the control plane and the rest two are the runtime clusters.
 
-![](https://static.kubevela.net/images/deploy_cloud.gif)
+![](https://kubevela.io/images/deploy_cloud.gif)
 
 Note that all the resources and statuses are aggregated and abstracted in the KubeVela Applications. Did any problems happen, it will pinpoint the problematic resources for users. This results in faster recovery time and more manageable delivery.
 
@@ -135,7 +135,7 @@ Finally, define the workflow of canary, approval, and notification:
 
 Here is a full demo:
 
-![](https://static.kubevela.net/images/rollout.gif)
+![](https://kubevela.io/images/rollout.gif)
 
 ## What Comes Next
 

diff --git a/blog/2022-01-27-blog-1.2.md b/blog/2022-01-27-blog-1.2.md
@@ -13,7 +13,7 @@ As the cloud native technologies grows continuously, more and more infrastructur
 
 This complexity and uncertainty has exacerbated the developer experience undoubtedly, reducing the delivery efficiency of business system, increasing the operational risks. The tenet of developer experience is simplicity and efficiency. Not only the developers but also the enterprises have to choose the better developer tools and platforms to achieve this goal. This is also the focus of KubeVela v1.2 and upcoming release that to build a modern platform based on cloud native technologies and covering development, delivery, and operations. We can see from the following diagram of KubeVela architecture that developers only need to focus on applications per se, and use differentiated operational and delivery capabilities around the applications.
 
-![image.png](https://static.kubevela.net/images/1.2/architecture.jpg)
+![image.png](https://kubevela.io/images/1.2/architecture.jpg)
 
 <!--truncate-->
 
@@ -44,14 +44,14 @@ It is the best choice to reduce developer learning curve by  providing an easy-t
 
 From GUI, users can manage addons, connect Kubernetes clusters, distribute delivery targets, set up environments and deploy all kinds of apps, monitor runtime status, achieve full lifecycle management of application delivery.
 
-![image.png](https://static.kubevela.net/images/1.2/dashboard.jpeg)
+![image.png](https://kubevela.io/images/1.2/dashboard.jpeg)
 pic 2. KubeVela Application Dashboard
 
 For the new terms in GUI, please refer to [Core Concepts](https://kubevela.io/docs/next/getting-started/core-concept) documentation to learn more details.
 ### Unified Multi-Cluster Control
 KubeVela will manage N Kubernetes clusters, N cloud vendor services in a big unified infrastructure pool. From that our developers can set up different environments based on business requirements, workflow policies, team collaboration needs, etc. This will create separate environment workspaces from big infrastructure resource pool. One application can be deployed into multiple environments, and environments are isolated from each other in both management and runtime.
 
-![image.png](https://static.kubevela.net/images/1.2/multiple-cluster.png)
+![image.png](https://kubevela.io/images/1.2/multiple-cluster.png)
 pic 3. KubeVela Application Status
 
 As shown above, an application can be deployed to default environments and other custom environments such as test or prod. Each environment can include multiple delivery targets. Each delivery target indicates an independent, separate Kubernetes cluster.
@@ -61,7 +61,7 @@ In terms of cloud native technologies, we have many options to pick for build ap
 
 With so many options, KubeVela adopts OAM as the standard application definition to manage heterogeneous application architecture uniformly. KubeVela provides highly extensible delivery core engine. Users can use built-in or install more plugins to extend the platform, and manage application deliveries in a consistent way. On top of KubeVela, what users see is the modular, everything-as-a-service control plane.
 
-![image.png](https://static.kubevela.net/images/1.2/cloud-resource.png)
+![image.png](https://kubevela.io/images/1.2/cloud-resource.png)
 pic 4. Cloud Resources Deploy
 
 As shown above, we can tell that in the application management page users can conveniently deliver cloud resources. Developers can read the following docs to understand the full delivery process of heterogeneous application architecture:
@@ -74,7 +74,7 @@ As shown above, we can tell that in the application management page users can co
 ### Extension System
 KubeVela has been designed as an extensible system from the very beginning. The aforementioned heterogeneous application architecture can be achieved via KubeVela's extension system. It can be extended via standard interfaces and plugin as many capabilities as you want. This will match the differentiated requirements of enterprises while reducing the cognitive burden incurred in learning new things. KubeVela's extension system includes component types, operational traits, workflow types, delivery policies, etc. In current release, we have the addon management system. An addon packages the extension capabilities for easy distribution.
 
-![image.png](https://static.kubevela.net/images/1.2/addon.png)
+![image.png](https://kubevela.io/images/1.2/addon.png)
 pic 5. KubeVela Addons
 
 Currently we provide an official catalog with pre-packaged addons shown as above. Meanwhile in the experimental catalog repo we can collaborating with community users to create more capabilities.
@@ -85,7 +85,7 @@ By now, KubeVela has grown into an application delivery platform that serve deve
 ### Multi-Cluster DevOps
 Today many enterprise software delivery looks like the following diagram. They use the compute resources from cloud vendors for both the demo and production environments. But they use their in-house server farm for the development or testing environments. If any business applications have multi-region disaster recovery requirements, then production environments can span multiple regions or even clouds.
 
-![image.png](https://static.kubevela.net/images/1.2/devops-en.png)
+![image.png](https://kubevela.io/images/1.2/devops-en.png)
 pic 6. DevOps Pipeline
 
 For basic DevOps workflow, it includes code hosting, CI/CD process. KubeVela can provide support for CD process. To enterprises the following are the practical steps:

diff --git a/blog/2022-06-10-visualize-resources.md b/blog/2022-06-10-visualize-resources.md
@@ -11,7 +11,7 @@ hide_table_of_contents: false
 
 One of the biggest requests from KubeVela community is to provide a transparent delivery process for resources in the application. For example, many users prefer to use Helm Chart to package a lot of complex YAML, but once there is any issue during the deployment, such as the underlying storage can not be provided normally, the associated resources are not created normally, or the underlying configuration is incorrect, etc., even a small problem will be a huge threshold for troubleshooting due to the black box of Helm chart. Especially in the modern hybrid multi-cluster environment, there is a wide range of resources, how to obtain effective information and solve the problem? This can be a very big challenge.
 
-![resource graph](https://static.kubevela.net/images/1.4/resource-graph.jpg)
+![resource graph](https://kubevela.io/images/1.4/resource-graph.jpg)
 
 As shown in the figure above, KubeVela has offered a real-time observation resource topology graph for applications, which further improves KubeVela's application-centric delivery experience. Developers only need to care about simple and consistent APIs when initiating application delivery. When they need to troubleshoot problems or pay attention to the delivery process, they can use the resource topology graph to quickly obtain the arrangement relationship of resources in different clusters, from the application to the running status of the Pod instance. Automatically obtain resource relationships, including complex and black-box Helm Charts.
 
@@ -124,7 +124,7 @@ For example, if we need to pay attention to whether the Service is correctly ass
 
 If there is only a resource relationship, it cannot solve our difficulties. We also need to be able to directly reflect exceptions, so that developers can have O(1) complexity when troubleshooting errors. Different resources have slightly different state calculations, but the general resource state has a Condition field that represents its final state. Based on this, the resource state calculation logic is formed by adding the state calculation method of a specific resource. We divide the resource state into normal, in-progress and abnormal, which are represented by blue, yellow and red border colors on the topology graph node, which is convenient for users to distinguish.
 
-![multiple-cluster-graph](https://static.kubevela.net/images/1.4/multiple-cluster-graph.jpg)
+![multiple-cluster-graph](https://kubevela.io/images/1.4/multiple-cluster-graph.jpg)
 
 In addition, different resources have different key information, such as whether PVC is bound, whether Pod instance is started, whether Service resource is associated with external IP and so on. These are called key information, and some information is displayed on the resource node bottom, others display when the mouse moves over the node. The information helps you quickly determine whether the resource configuration is correct and its status is normal.
 

diff --git a/blog/2022-06-21-release-1.4.md b/blog/2022-06-21-release-1.4.md
@@ -77,13 +77,13 @@ Another big demand in application delivery is the transparent management of the
 In Version 1.4, we added the resource topology query function to improve KubeVela's application-centric delivery experience. When developers initiate application delivery, they only need to care about simple and consistent APIs. When they need to troubleshoot problems or focus on the delivery process, they can use the resource topology feature to quickly obtain the orchestration relationships of resources in different clusters **from applications to the running status of Pod instances and automatically obtain the relationships of resources, including complex and black-box Helm Chart.** 
 
 
-![resource graph](https://static.kubevela.net/images/1.4/resource-graph.jpg)
+![resource graph](https://kubevela.io/images/1.4/resource-graph.jpg)
 
 The application shown in the preceding figure is used as an example. A Redis cluster is delivered through the Helm Chart package. The first layer of the chart is the application name, the second layer is the cluster, and the third layer is the resources directly rendered by the application. The next third and fourth layers are the associated resources of the lower level tracked according to different resources. 
 
 Users can use graphs to observe the derived resources and their status during the application delivery process. The abnormal points are displayed in yellow or red and the specific reasons are displayed. Compared with the application shown in the following figure, it is a basic Webservice delivered to two clusters. Developers can find that the application creates Deployment and Service resources in the two clusters, respectively. Also, the Deployment resources in the ask-hongkong cluster are displayed in yellow since the Pod instance has not been fully started. 
 
-![multiple-cluster-graph](https://static.kubevela.net/images/1.4/multiple-cluster-graph.jpg)
+![multiple-cluster-graph](https://kubevela.io/images/1.4/multiple-cluster-graph.jpg)
 
 
 This feature also allows you to search, filter, and query using different clusters and components. This helps developers quickly identify problems and understand the delivery status of the underlying application at a very low threshold. 
@@ -141,7 +141,7 @@ Our plug-in ecology is also rapidly expanding because of the improvement of the
 
 Developers are welcome to participate in the community and [create addon](https://kubevela.net/docs/platform-engineers/addon/intro) to extend KubeVela's system capabilities. 
 
-![undefined](https://static.kubevela.net/images/1.4/addon-list-new.jpg) 
+![undefined](https://kubevela.io/images/1.4/addon-list-new.jpg) 
 
 ## How Can You Participate in the Community?
 

diff --git a/blog/2022-06-27-terraform-integrate-with-vela.md b/blog/2022-06-27-terraform-integrate-with-vela.md
@@ -145,7 +145,7 @@ In this part, we will introduce a solution that you can expose any of your Kuber
 * Install KubeVela
 
 ```
-curl -fsSl https://static.kubevela.net/script/install-velad.sh | bash
+curl -fsSL https://kubevela.io/script/install-velad.sh | bash
 velad install
 ```
 

diff --git a/blog/2022-08-17-helm-rollout.md b/blog/2022-08-17-helm-rollout.md
@@ -46,7 +46,7 @@ Let's take you through a practical example (using Deployment Workload as an exam
 - Install KubeVela
 
 ```shell
-$ curl -fsSl https://static.kubevela.net/script/install-velad.sh | bash
+$ curl -fsSL https://kubevela.io/script/install-velad.sh | bash
 velad install
 ```
 

diff --git a/blog/2022-09-17-release.1.5.md b/blog/2022-09-17-release.1.5.md
@@ -16,7 +16,7 @@ hide_table_of_contents: false
 
 KubeVela has released five major versions over the past year. Each iteration is a leap forward. The release of version 1.1 brought the ability to connect multiple clusters. Version 1.2/1.3 brought an extended system and a more developer-friendly experience. Version 1.4 introduced a security mechanism in the complete process. The release of 1.5 today brings us closer to KubeVela's vision of *making application delivery and management easier.* Along the way, we have stayed true to the same design philosophy and built a platform that automates the complexity of the underlying differentiated infrastructure without losing scalability. It helps application developers upgrade from business development to cloud-native R&D at a low cost. Technically, it focuses on the complete process from code to cloud and from application delivery to management. It refines the framework capabilities of connecting infrastructure based on the Open Application Model (OAM). As shown in Figure 1, KubeVela has covered the complete capabilities of application definition, delivery, O&M, and management, all of which are based on OAM scalability (OAM Definition) to connect to ecological projects in an addon way. **In essence, each definition converts the experience of a specific capability into a reusable best practice module, which can be shared by enterprises or communities through addon packaging.** 
 
-![kubevela-extensibility](https://static.kubevela.net/images/1.5/kubevela-extensiblity.png)
+![kubevela-extensibility](https://kubevela.io/images/1.5/kubevela-extensiblity.png)
 
 *Figure 1: Core Structure of KubeVela Extensibility*
 
@@ -44,15 +44,15 @@ Please refer to [the document](https://kubevela.net/docs/platform-engineers/addo
 
 Here is an example of integrating the delivery capability of the Helm Chart package. Currently, projects in the community like FluxCD or ArgoCD provide the atomic capability of deploying Chart packages. Their implementations are different, and each has its advantages. For KubeVela users, these two projects can be introduced through addons. As shown in Figure 2, we need to define a standard API for the end user to expose the necessary parameters to the end user according to the specific situation of the enterprise. 
 
-![kubevela-helm](https://static.kubevela.net/images/1.5/kubevela-helm.png)
+![kubevela-helm](https://kubevela.io/images/1.5/kubevela-helm.png)
 
 *Figure 2: Process of KubeVela Extending the Helm Chart Package*
 
 As shown in Figure 3, according to the standard API, the frontend UI can automatically generate the corresponding interactive page to help the end user easily and conveniently deploy the Helm Chart package. The platform side automatically generates the driver configuration of the underlying capability based on the user's input parameters and addon definitions and intelligently sends the relevant status feedback to the user. These are based on addon specifications, such as integrating FluxCD. This project includes multiple controllers providing different atomic capabilities. First, we use template.cue to define the deployment method of FluxCD and deploy different components based on different parameter inputs. Then, the user experience is defined by definitions and schema directories. 
 
 Please see [this link](https://github.com/kubevela/catalog/tree/master/addons/fluxcd) for more information.
 
-![helm-ui](https://static.kubevela.net/images/1.5/helm-ui.png)
+![helm-ui](https://kubevela.io/images/1.5/helm-ui.png)
 *Figure 3: Interaction for KubeVela to Deliver Helm Chart Packages*
 
 ## Function Interpretation Based on Addon Extensions
@@ -72,12 +72,12 @@ The system of application observability is closely related to application releas
 Figure 4 shows the dashboard of KubeVela system operating indicators. The dashboard is automatically generated through the IaC system. You only need to enable the corresponding addon. 
 
 
-![system dashboard](https://static.kubevela.net/images/1.5/system-dashboard.png)
+![system dashboard](https://kubevela.io/images/1.5/system-dashboard.png)
 *Figure 4: KubeVela System Observable Dashboard*
 
 Figure 5 shows the monitoring dashboard of the Kubernetes API Server service connected to KubeVela. Use addons to issue Exporters to all sub-clusters, expose data to the Prometheus service of each cluster, and aggregate it to the control cluster for centralized visualization. You can complete the data monitoring and dashboard access of many clusters at the same time. 
 
-![apiserver dashboard](https://static.kubevela.net/images/1.5/apiserver-dashboard.png)
+![apiserver dashboard](https://kubevela.io/images/1.5/apiserver-dashboard.png)
 *Figure 5: KubeVela Multi-Cluster API Observation Dashboard*
 
 In the next release, the community will gradually integrate the unified description and delivery of application observability into the application delivery process. It covers Metric, Logger, and Tracing data acquisition, intermediate processing and transmission, storage and analysis, alerts and visualizations, and applications to the complete process of the application release workflow. 
@@ -99,7 +99,7 @@ Manipulating application delivery through a CLI black screen is convenient, easi
 
 5. **Data Automatic Synchronization:** CLI can create and update applications. Changes will be visualized on the UI until the user chooses to take over the application and subsequent releases through UI. 
 
-![cloud shell](https://static.kubevela.net/images/1.5/cloud-shell.png)
+![cloud shell](https://kubevela.io/images/1.5/cloud-shell.png)
 *Figure 6: KubeVela CloudShell Operating Terminal*
 
 ### Integrate OpenKruise Rollout to Provide Canary Release Capabilities
@@ -120,7 +120,7 @@ VelaUX has had the multi-environment deployment capability since its launch. Unt
 
 As shown in Figure 7, the Application Policy has a variety of available options built in, including differentiated configuration, application multi-cluster policies, application maintenance policies, and GC policies. Users can easily configure corresponding policies according to their needs through UI guidance. 
 
-![create policy](https://static.kubevela.net/images/1.5/create-policy.png)
+![create policy](https://kubevela.io/images/1.5/create-policy.png)
  *Figure 7: KubeVela Policy Add/Edit Window*
 
 In version 1.5, the following convenient features are added before and after deployment for different environments: