In today's fast-paced digital world, ensuring the uptime and reliability of web services is crucial. 

Uptime Kuma, a self-hosted monitoring tool

, has become a popular choice for many. When deployed on platforms like Zeabur, it offers enhanced convenience and efficiency. This guide provides a detailed walkthrough on how to deploy Uptime Kuma on Zeabur with just one click.

Uptime Kuma is an open-source monitoring solution that helps you keep track of your website's uptime and response time. It's designed to be a more privacy-conscious alternative to third-party services.

: Tracks your website’s uptime continuously.

: Notifies you through various channels when your site is down.

Zeabur is a cloud platform that simplifies the deployment and management of applications. It's known for its user-friendly interface and one-click deployment features.

: Intuitive UI for straightforward application management.

: Easily scales resources according to your needs.

: Implements robust security measures to protect your applications.

Before starting, ensure you have a Zeabur account and understand the basics of navigating its dashboard.

: Create a project, and then click on the **Deploy New Service** button to find Uptime Kuma in the prebuilt marketplace. Zeabur will start the deployment for you after you select Uptime Kuma.

 You can bind a domain for your Uptime Kuma service in the domain tab.

: Check if Uptime Kuma is running correctly.

: Configure your sites or services to be monitored.

Deploying Uptime Kuma on Zeabur with one click is a seamless process that enhances your website monitoring capabilities. By following this guide, you can quickly set up a robust monitoring system.

For more detailed tutorial, you can check 

Deploy Uptime Kuma in 3 Minutes

On October 27, 2023, Zeabur experienced a service outage. The outage affected the tpe1 cluster located in the Taipei region, resulting in a service interruption of approximately 1 hour. The cause of the outage was a mistake made by an intern, leading to the deletion of our Kubernetes cluster located in the Google Cloud Platform's Taipei data center.

Upon receiving alerts from the monitoring service, Zeabur's operations team acted swiftly and restored services for both enterprise and developer users within two hours. The scope of the outage was relatively broad, with the main users affected including:

Containerized services of the free, developer, and enterprise plans deployed in the tpe1 (Taipei) region

Serverless services of the free, developer, and enterprise plans deployed in the tpe1 (Taipei) region

If your deployed services happen to be in the affected region, then you might have been unable to access the services you deployed on Zeabur during this time on October 27, 2023.

We deeply apologize for the mistakes made during this incident and the resulting impact.

During the process of deleting an obsolete test cluster, an intern, due to lack of operational experience and internal oversight in permission management, failed to report this risky operation to supervisors. Mistakenly, the production Google Kubernetes Engine cluster was deleted, causing it to become unavailable and all services in the tpe1 (Taipei) region to be disrupted.

UTC 2:40 - tpe1 cluster is deleted, all services go offline. 

UTC 2:41 - The service health monitoring system detects the interruption and sends an emergency alert to the project monitoring team. 

UTC 2:45 - The cause of the outage is identified. Operations staff immediately start investigating and discover the cluster is inaccessible. Further inspection reveals the cluster has been deleted and the process is irreversible. The team initiates emergency response measures. 

UTC 2:50 - After attempting to communicate with Google Cloud Platform, the project tech lead and operations staff try to directly restore the cluster but fail. They attempt to restore the cluster using Google Kubernetes Engine backup, but upon inspection, it's found that the backup service was not enabled for this cluster. 

UTC 3:00 - Team investigations reveal that the deleted cluster does not affect the Persistent Disk in Google Cloud Platform's Compute Engine, confirming that user service data has not been lost. 

UTC 3:10 - The process of migrating disrupted services to the tpe0 (Taipei) region begins. The team starts re-linking user data to a backup cluster in the Taipei region through automation scripts. 

UTC 3:30 - The primary functions of the cluster are restored, user services go back online, services for enterprise plan customers are restored, and the development team starts addressing user-reported tickets. 

UTC 3:48 - The team issues an outage announcement, suggesting users temporarily migrate stateless services to the hkg1 (Hong Kong) or sfo1 (North America) regions as a temporary solution. 

UTC 3:56 - The team releases a service recovery statement, offering users a solution and a process for ticket submission. 

UTC 6:10 - The team announces full service restoration. All tickets from developer plan customers submitted during the outage are resolved. They set up a ticket submission process for user service recovery requests and continue restoring services for users.

A lack of security awareness among employees. Before executing dangerous operations, they did not promptly report to supervisory developers for review and failed to double-check the targeted resources.

In-house permission management was not granular enough. This led to employees having administrative access to the production environment clusters, without specific access controls.

The disaster recovery plan was inadequate. Kubernetes resources were not backed up automatically on a regular basis, making it impossible to rapidly restore from backups after an incident.

There was a lack of established emergency response procedures for related urgent situations, leading to longer response times.

The monitoring system rapidly detected multiple 502 errors across various services, and a large number of alarms were triggered in a short time. Investigation showed that all issues were originating from the `TPE1` cluster. Subsequent internal checks within the development group revealed that there was an operation to delete the development cluster within a minute. However, due to the failure to report to the supervisory developers for review in time, and continuously operating under a high-privilege account, the production cluster was accidentally deleted.

In the shortest possible time, the development team initiated emergency measures. Engineers from the team contacted Google Cloud Platform customer service and confirmed that once a deletion operation is executed, it cannot be reversed. Moreover, since the Google Kubernetes Engine backup function was not enabled, it was impossible to restore the cluster through this method.

Upon team investigation, it was determined that the persistent storage hard drives of the cluster were not destroyed due to the cluster deletion. Therefore, the decision was made to manually create new stateful services in the backup cluster by binding to the original hard drives. Stateless services were rebuilt from scratch.

Infrastructure operations engineers increased computing nodes in the Taipei backup cluster, `tpe0`, creating new deployments to accommodate user services from the faulty cluster. Once the cluster was ready, the team started restoring user services using automated scripts and the original persistent hard drives. 

Thanks to the robustness of the existing Zeabur system and some straightforward migration scripts, the development team quickly transferred services to the backup cluster. After validating the feasibility of experimental manual migration, services for enterprise solution users were given priority for restoration.

Once the migration of affected users' clusters was completed, the services for enterprise solution users were restored. The development team then began addressing user tickets. Services for developer plan users and free plan users began to be restored gradually through a refined automated process.

Updated Emergency Plan: Users can temporarily migrate stateless services to the Hong Kong `HKG1` cluster or the US `SFO1` cluster as a solution. Stateful services, on the other hand, will be transferred to temporary clusters to effectively safeguard the integrity of user data.

Upon verification, it was confirmed that the business system can start correctly on the backup cluster and provide services to the outside world, resolving the service interruption incident.

After the emergency event concluded, the team immediately minimized control by deactivating all IAM permissions of the developers. Simultaneously, a security inspection of all infrastructure was undertaken, identifying several potential security risks and formulating an improvement plan.

Once all clusters were restored to normal, operational engineers activated the backup service for every cluster, performing a full backup. Regular backup services were initiated to incrementally back up user data at set intervals.

The team summarized and analyzed the event, reflecting and improving on the mistakes made during the incident. There was also a reassessment and redesign of the infrastructure's high availability and security.

 For the occasional errors that continued to appear in user services, the team established a service recovery reporting process to ensure quick responses and high availability for service recovery work orders:

 and submit a ticket on Zeabur's official 

The official Zeabur team will handle the ticket. For user recovery requests, we commit to completing service recovery within 10 minutes.


Strengthen security and standardized operational training for employees and interns. Any modifications to the production environment require review by a senior engineer. Once approved, the operation will be performed by the senior engineer. If feasible, a mechanism for restoration should always be available.


1. Following this incident, a complete redesign of IAM permission management was undertaken internally to ensure all developers are granted only the minimum required permissions.

2. For destructive operations (especially those irreversible), developers must manually assume the role for resource operations. This adds an extra layer of confirmation to ensure such oversights don't recur.

3. Both the monitoring system and management team will receive alerts when sensitive operations roles are assumed, allowing immediate rectification of potential mistakes.


Set protective locks on crucial system resources to prevent erroneous modifications and deletions. Risky operations would require system administrator authentication and Multi-Factor Authentication (MFA).


Based on this experience, Zeabur's disaster recovery and response measures for single-region failures were redesigned. By backing up Kubernetes resources and user service container images, we can ensure service restoration within 15 minutes in the worst-case scenarios.

Additionally, the team decided to enhance backup levels for persistent user service data. Cross-region backups for persistent data from enterprise and developer solutions ensure Zeabur user data safety, even in the event of upstream provider failures.


The monitoring alert system will be improved to identify anomalies in infrastructure operations in real-time. Operations logs from upstream systems, such as AWS CloudTrail and Google Cloud Audit Logs, will be integrated into Zeabur's internal management system. Using Clickhouse and Grafana, corresponding alert rules will be set to promptly identify risky operations.


Zeabur has always been dedicated to delivering a highly available service deployment experience. However, this incident showed we haven't met our own standards. Through this, we've recognized shortcomings in infrastructure security management and high-availability design. We are committed to learning and improving to prevent similar incidents. We deeply apologize to all users who couldn't access Zeabur services during this outage. Improvements and reflections are underway to ensure such events do not reoccur.

Zeabur Taipei region outage on October 27, 2023

2023 年 10 月 27 日，Zeabur 發生了一次服務中斷故障事件。故障影響到位於台北區域的 tpe1 叢集 ，導致服務中斷 1 小時左右。故障的起因是一名實習生操作失誤導致刪除了我司位於 Google Cloud Platform 台北機房的 Kubernetes 叢集。

Zeabur 的運維團隊在接收到監控服務報警後迅速採取行動，在兩小時內復原了企業方案及開發者方案使用者的服務。此次故障影響範圍較為廣泛，主要受影響的使用者包括：

部署在 tpe1（台北）區域的免費方案、開發者方案、企業方案使用者的容器化服務

部署在 tpe1（台北）區域的免費方案、開發者方案、企業方案使用者的 Serverless 服務

如果您部署的服務恰好在受影響的區域內，那麼在 2023 年 10 月 27 日的這段時間內，您可能會無法訪問您在 Zeabur 部署的相關服務。

我們對此次事件的失誤和造成的影響深感歉意。

公司實習生在刪除原有廢棄的測試叢集時，由於缺乏操作經驗，以及內部權限管理的疏失，並且未將危險操作行為上報給主管人員，錯誤地將生產環境的 Google Kubernetes Engine 叢集刪除，導致叢集進入不可用狀態， tpe1（台北）區域的服務全部中斷。

UTC 2:40 - tpe1 叢集被刪除，服務全部離線。

UTC 2:41 - 服務健康監控系統檢測到服務中斷，向專案監控小組發送緊急報警。

UTC 2:45 - 故障原因確認，運維人員立即進行排查，發現叢集無法訪問。進一步排查發現叢集被刪除，並且過程不可逆，團隊開始緊急應變措施。

UTC 2:50 - 專案技術負責人及運維人員在嘗試和 Google Cloud Platform 溝通後嘗試直接修復叢集失敗，嘗試通過 Google Kubernetes Engine 備份復原的方式復原叢集，但是經排查該叢集並未啟用備份服務。

UTC 3:00 - 經過團隊排查，發現被刪除的叢集不影響使用 Google Cloud Platform 中 Compute Engine 的 Persistent Disk，因此確定使用者服務資料並未遺失。

UTC 3:10 - 開始將故障服務遷移至 tpe0（台北）區域，團隊開始透過自動化腳本將使用者的資料重新綁定至位於台北區域的備援叢集。

UTC 3:30 - 叢集主要功能復原，使用者服務重新上線，企業方案客戶服務復原，開發團隊開始處理使用者回報的工單。

UTC 3:48 - 團隊發表故障公告，並建議可以臨時遷移無狀態服務至 hkg1（香港）區域或 sfo1（北美）區域作為臨時解決方案。

UTC 3:56 - 團隊發表服務復原宣告，向使用者給出解決方案以及工單提交流程。

UTC 6:10 - 團隊發表服務復原公告，所有故障期間發布的開發者方案客戶工單處理完畢，制定使用者服務復原申請的工單提交流程，持續為使用者復原服務。

員工安全意識缺乏，在危險操作前沒有及時上報給主管開發人員覆核，也沒有重複確認操作的目標資源。

團隊內部權限管理不夠細粒度，導致員工擁有生產環境叢集的管理權限，沒有進行針對性的權限控制。

災備方案不夠完善，Kubernetes 資源沒有定期自動備份，導致故障發生後無法快速透過備份進行復原。

缺乏相關緊急情況的應急處理流程，導致反應時間較長。

監控系統快速檢測到多個服務出現 502 錯誤，並且在短時間內出現大量報警，經排查所有項目均來自於 `TPE1` 叢集。隨後在開發組內部確認，團隊在 1 分鐘內有刪除開發叢集的操作，但是由於沒有及時上報給主管開發人員覆核，同時帳戶策略一直在使用高權限帳戶，導致誤刪除了生產叢集。

在最短的時間內，開發團隊開始緊急處理，團隊工程師詢問了 Google Cloud Platform 客服，確認刪除操作一旦執行不可復原。並且因為 Google Kubernetes Engine 備份功能未啟用，無法透過此方式復原叢集。

經過團隊排查，叢集的持久化儲存硬碟並未因為叢集的刪除動作而被銷毀，因此決定手動透過綁定原有硬碟的方式在備援叢集建立新的有狀態服務，無狀態服務則採用重新構建的方式。

基礎設施運維工程師，在台北備援叢集 tpe0 增加計算節點，建立新的部署以容納來自故障叢集的使用者服務。叢集準備就緒後，團隊開始透過自動化腳本透過原有的持久化硬碟復原使用者服務。得益於 Zeabur 原有系統的健壯性，透過一些簡單的遷移腳本，開發團隊得以快速將服務遷移到備援叢集。實驗性手動遷移工作的可行性驗證後，優先復原企業方案使用者的服務。

故障使用者的叢集遷移完成，企業方案使用者服務復原。開發團隊開始處理使用者工單。開發者方案使用者和免費方案使用者服務開始透過完善的自動化流程逐步復原。

後續應急方案更新：使用者可以臨時遷移無狀態服務至 香港 `HKG1` 叢集或 美國 `SFO1` 叢集作為解決方案。有狀態服務則遷移至臨時叢集，有效保護使用者資料的完整性。

經驗證，業務系統在備援叢集上能夠正確啟動和對外提供服務，服務中斷事件得以解決。

在應急事件結束後，團隊第一時間關閉了所有開發人員的 IAM 權限帳戶進行了最小化控管，同時對於所有的基礎設施進行了安全檢測，發現了一些潛在的安全隱患並制定改進計畫。

在所有叢集復原正常狀態後，運維工程師對所有叢集開啟了備份服務，並且對於所有的叢集進行了全量備份。開啟定時備份服務，對於使用者資料進行定時增量備份。

團隊對於事件進行了總結和分析，並且對於事件中的失誤進行了反思和改進，同時對於基礎設施的高可用性和安全性進行了重新評估和設計。

對於偶發的使用者服務仍然持續出現錯誤的情況，團隊制定了服務復原工作的回報流程，保證服務復原工單的快速應答和高可用：

- 由 Zeabur 官方團隊進行工單處理，對於使用者的復原請求，我們將在 10 分鐘完成服務復原工作。

強化員工和實習生的安全和規範化操作培訓，修改生產環境前需要上級主管工程師覆核。審批通過後，由主管工程師進行操作。如果條件允許，將確保復原機制可用。

1. 在此次事件後，團隊內部針對 IAM 權限管理進行了完整的重新設計，確保所有開發人員只獲得最小化的操作權限。

2. 對於破壞性的操作（尤其是不可復原的破壞性操作），確保開發人員必須在手動 assume（假設）資源操作角色後，才能獲得對應的權限，多一次重複確認的動作來確保這類疏失不再發生。

3. 監控系統和管理團隊也能在當敏感操作對應的角色被 assume 時收到監控報警，即時避免錯誤的操作。

在關鍵系統資源上設定保護性鎖定，避免錯誤的修改和刪除。危險操作需要系統管理員認證和 MFA 多因素裝置輔助認證。

基於此次經驗，我們重新設計了 Zeabur 對於單區域性故障的災備策略和應變措施。透過備份 Kubernetes 資源、使用者服務的容器 Image，我們可以確保在最糟的情況下仍能在 15 分鐘內復原服務。

同時，團隊也決定提升使用者服務的持久化資料的備份等級，為企業方案和開發者方案客戶部署的服務的持久化資料進行跨區備份，確保即使上游供應商發生故障，也能保障 Zeabur 使用者的資料安全。

完善監控報警系統，對於基礎設施操作接入報警系統，及時發現異常操作。我們將來自上游系統（如 

）的操作記錄接入到 Zeabur 內部的管理系統中，使用 Clickhouse 及 Grafana 設定對應的報警規則，確保危險操作在可能發生時能夠被即時確認。

Zeabur 一直致力於打造高可用的服務部署體驗，但這次意外事件表明，我們顯然沒有達到預期。透過這次事件，我們注意到在基礎設施安全管理和高可用架構設計上還有很多不足，會認真總結和改進以預防類似事件再次發生。在此對所有在本次服務故障事件期間無法訪問 Zeabur 服務的使用者深表歉意。我們已經開始改進和反思，確保類似情況不會再次發生。

2023 年 10月 27 日 Zeabur 台北區域服務故障報告

 that gives you building blocks to create fast 

: Successful passage of 5,000 tests for both App & Pages Router.

Seamlessly combined with cache and revalidation.

Execute with basic function commands or sync effortlessly with forms.

: Swift primary static output coupled with streaming of dynamic data.

To start, we need to prepare the application. Launch your terminal and execute the command below to set up the CLI.

After you’ve created the application, you will get a project with a structure like the following picture.

And as you can see, the app we’ve created is using Next.js 14.0.0 now.

Then, you just need to create a remote repository to store your codes.

If you haven't set up a Zeabur account yet, you'll want to do so once your repository is prepared.

 and click on the Get Started button. A modal will appear showcasing a 'login with GitHub' button. Click on it, grant Zeabur permission to connect with your GitHub, and voila! You'll have your Zeabur account set up.

In the dashboard of Zeabur, press on the 

 button to select a region you prefer, then Zeabur will create a project in the selected region for you.

On the project page, find and select the Deploy New Service button. From there, choose Deploy from GitHub. Lastly, hit the configuration button to grant Zeabur permission to your repository.

Once you've completed the configuration, simply locate your application and select it to initiate deployment.

It'll take roughly 3 minutes for the build process, after which your Next.JS application will be up and running.

As you can see, Zeabur will automatically detect that your application’s framework is Next.JS.

If you wish to access your application, you must assign a domain to it. Navigate to the domain tab within the service page. There, you have the option to select 

 to avail of a complimentary domain with a 

 extension. Choose an appropriate domain, hit save, and then you're all set to access your service via the chosen domain.

How to Deploy Next.JS 14 Application in 3 Minutes

NestJS is a framework for building efficient, scalable 

 server-side applications. It uses progressive JavaScript, is built with and fully supports 

 and combines elements of OOP (Object Oriented Programming), FP (Functional Programming), and FRP (Functional Reactive Programming).

First of all, let’s get the application ready. You can use NestJS CLI to bootstrap a new application. Open your terminal and run the following command to install the CLI.

Then you can create a NestJS application with a single command.

You can also clone a starter template in our GitHub.

`git clone https://github.com/zeabur/nestjs-template.git <your project name>`

After you’ve created or cloned the application, you will get a project with a structure like the following picture. 

Let’s take a look in the `main.ts` file, which is the entry of your application.

As you can see, NestJS will use a function called NestFactory to create your application from the app.module, and run the application on port 3000. You can use npm run start to start the application, and open 

 in your browser, you can see the welcome page of your NestJS app.

When it comes to deploy in your production environment on Zeabur, you shouldn’t use the port 3000 anymore, you need to read from process environment. You can change the port 3000 to process.env.PORT.

Now your NestJS is ready for deploying on Zeabur, all you need is to push the codes to your GitHub.

After your repository is ready, you need to register a Zeabur account if you still don’t have one.

, press the Get Started button, and you will see a modal with a login with GitHub button, press the button and authorize Zeabur to access your GitHub, then you will get an account on Zeabur.

In Zeabur dashboard, press on the Create Project button and select a region you prefer, Zeabur will initialize a project in the region for you, and you will be automatically redirected to the project.

In the project page, click on `Deploy New Service` button, select `Deploy from GitHub`, and click on the configuration button to let Zeabur get access to your repository.

After the configuration is finished, just search your application and click on it to start the deployment.

The building process will last about 3 minutes, and your NestJS app is ready.

As you can see, Zeabur will automatically detect that your application’s framework is NestJS.

To visit your application, you need to bind a domain for it. Open the domain tab in the service page, you can choose Generate Domain to use a free domain with .zeabur.app suffix. Pick a valid domain and click save, then you can visit your service with the domain.

: A Node.js framework that uses TypeScript, blending OOP, FP, and FRP.

Bootstrap with NestJS CLI or use Zeabur's GitHub template.

Create a project, select region, then deploy the app using 'Deploy from GitHub'. Zeabur auto-detects the NestJS framework.

Bind a domain for accessibility. Use Zeabur's 'Generate Domain' for a free 

Deploy NestJS Application on Zeabur: A Step by Step Guide

For a better reading experience, let me introduce you some basic concepts of Zeabur.

Zeabur is a platform that helps developers to deploy painlessly and scale infinitely.

There are 3 levels of application in Zeabur: Project, Service and Deployment.

Service can be imported from a GitHub repo or a prebuilt image, one service is usually used for one specific task, like a website or a database.

A project is typically made up of multiple services, which are designed to work together seamlessly to achieve a common goal. These services are often connected to a private network, which can improve communication between them and make it easier to manage the flow of data and information.

Within each service, there may be many different deployments, each of which is designed to handle a specific version of the service. This allows developers to make changes and updates to the service over time, without disrupting the overall functionality of the project as a whole.

The CLI (command-line interface) is a powerful tool that allows users to interact with their operating systems through text-based commands. By leveraging the CLI, users can execute a wide range of functions, from basic tasks like creating and deleting files, to more complex operations like configuring network settings and managing system processes.

It is an essential tool for anyone looking to take control of their operating system and maximize their productivity. While it can be intimidating at first, especially for users who are accustomed to GUIs, the benefits of the CLI are well worth the effort required to learn its ins and outs.

Nowadays, almost all the software applications are designed with a great graphical user interface (GUI) to provide an enhanced user experience. However, it is important to note that the command-line interface (CLI) is still a vital part of many software applications. While the GUI provides a user-friendly approach to interact with software, the CLI offers a powerful way to perform complex tasks with efficiency and flexibility.

Most of Zeabur's users are developers who use terminals daily. Therefore, using CLI to monitor and manage services deployed on Zeabur may be more convenient.

For a better develop experience, we use Cobra as our CLI framework.

Zeabur follows the principle of "Dependency Inversion, not Dependency on Implementations", abstracting all functions as interfaces and putting them all into `cmdutil.Factory`. The corresponding implementation is injected into the `Factory` during project initialization, instead of being called directly in the code.

This is the definition of Factory. As you can see, whether it's logging, API calls, or interactions, they are all defined as interfaces.

The benefits of this approach are significant:

Decoupling of code, making it easy to replace/extend implementations (e.g. replacing the default GraphQL implementation of ApiClient with RESTful)

Facilitates testing, as it is easy to mock the corresponding implementation

Facilitates integration into external projects

 to generate corresponding mock implementations, which are convenient for unit testing.

We also wrote a mock implementation specifically for zap (logging) for unit testing. This implementation can output logs to a string array during testing, enabling log comparison level unit testing.

When it comes to implementing authentication in CLI applications, there are several approaches that can be taken. For example, one approach is to use a third-party authentication provider, which can simplify the process and provide additional security features. Another option is to implement a custom authentication solution, which can be tailored to the specific needs of the application. Additionally, some CLI applications may benefit from integrating with existing authentication systems, such as OAuth or LDAP, which can provide a more seamless user experience.

In our situation, we use OAuth for our auth system in CLI, with 

. You can use `zeabur auth login` in our CLI, and we it will open your browser with our auth website to request the auth server for a token. After pressing the confirm button, CLI will automatically get your account information in Zeabur.

The principle is as follows: CLI starts an HTTP service in the background, listens on a random port, acts as an OAuth2 client, and then opens a browser to complete the login through Zeabur OAuth Server. We also have a built-in Refresh Token mechanism, which refreshes the token as needed by default after each command ends.

As its is mentioned above, Zeabur has designed the concept of context, which can be specified by using `zeabur context set <project|service|environment>` to set the default context.

Similarly, when setting the context with set, it is possible to select it interactively without having to remember the ID or Name.

We have designed a BasicInfo interface to abstract the corresponding basic information, such as Project, Service, Environment.

Whenever the context is updated, the corresponding information will be stored in the configuration file of Zeabur CLI (`~/.config/zeabur/cli.yaml`).

 for automatic versioning. The CLI is published to Homebrew, Scoop, Install Script, and more by triggering GitHub Action with git tag.

Thanks to our great community, Zeabur CLI now supports `brew install` two days after its initial publication. This feature was made by 

Zeabur CLI is a command-line interface tool that is currently in the beta stage of development. Your input will help us ensure that Zeabur CLI is the best tool it can be, and we are grateful for any assistance you can provide us with. We welcome all contributions, big or small, and we encourage you to contact us with any questions or feedback you may have.

Zeabur CLI

A visual analysis tool is a software or program that helps users analyze and interpret visual data or information. It allows users to explore and examine data through various visual representations, such as graphs, charts, and maps. These tools often come with features that aid in data filtering, sorting, and manipulation, enabling users to identify patterns, trends, and insights that may not be immediately apparent. The goal of a visual analysis tool is to make complex or large data sets more understandable and accessible to users by presenting it in a visually appealing and interactive format.

Visual analysis tools have become essential in helping individuals and organizations gain insights from complex and vast amounts of data efficiently, facilitate decision-making processes, and improve communication and collaboration.

 is not just an open-source alternative to Data Analysis and Visualization tools such as Tableau, but it automates your Exploratory Data Analysis workflow with an Augmented Analytic engine by discovering patterns, insights, causals and presents those insights with powerful auto-generated multi-dimensional data visualization.

: Rath is fully open-source. So it’s freely to use and to be modified to meet specific needs.

: Rath provides a fully-automated way to explore and visualize dataset easily with AI empowered. It can work as your copilot in data science.

: Rath has a user friendly interface as a web application. Directly coloring your data makes your data analysis more easily and intersting.

: Rath also provides an option to let you talk to your data with natural language. You can simply talk to your data to get the analysis results.

Trifacta is "designed for analysts to explore, transform, and enrich raw data into clean and structured formats." Trifacta utilizes techniques in machine learning, data visualization, human-computer interaction, and parallel processing so non-technical users can work with large datasets.

: Trifacta provides a super fun drag and drop experience.

: Data wrangling allows all users within an organization to explore and prepare the data. This means the subject matter experts, regardless of data architecture level, will be able to work directly with the data and transform it into the right form.

 is a business intelligence platform from Microsoft. It offers data analytics tools and services for visualizing data, creating dashboards, and sharing insights. It allows users to connect to multiple data sources, clean and transform data, create custom calculations, and visualize data through charts, graphs, and tables.

: Power BI enables users to create and manage relationships between different data sources, define calculations, and develop measures and KPIs.

: Power BI allows users to share and collaborate on reports and dashboards with colleagues and integrate with other Microsoft tools like Excel, SharePoint, and Teams.

AI tools such as GitHub Copilot and ChatGPT have the amazing capability to empower people and transform them into developers. This democratization of development means that anyone, regardless of prior coding experience, can now participate and contribute to the world of software development.

Similarly, the integration of AI capabilities into data visualization tools has the potential to make data science accessible to a wider audience. With data visualization tools powered by AI, individuals can easily transform raw data into visually appealing and meaningful representations. Individuals without extensive data analysis skills can leverage AI-powered tools to uncover patterns, trends, and valuable information hidden within their data.

, Rath is a cutting-edge data analysis tool that was among the pioneers in integrating artificial intelligence into its functionality. For people without any prior data analysis experience, Rath can be their AI assistant for automated generating visualizations with insights from datasets. Every one can be a data scientist with Rath’s supports.

Zeabur Blogs

Deploy Uptime Kuma in 3 Minutes

Zeabur Taipei region outage on October 27, 2023

2023 年 10月 27 日 Zeabur 台北區域服務故障報告

How to Deploy Next.JS 14 Application in 3 Minutes

Deploy NestJS Application on Zeabur: A Step by Step Guide

Zeabur CLI

Visual Analysis Tool Face-off: Rath vs Trifacta vs Power BI

Product

Company

Contact

Legal

Product

Company

Contact

Legal