Kliv
    雲端後臺

    真正的後端,與你的應用程式一起誕生

    資料庫、登入、檔案、功能、機密、電子郵件 — 每個 Kliv 應用程式都從所有這些開始,在你建置時由 AI 建置和管理。無需配置、無需連線、無需保持同步。

    價格

    雲端後臺

    不是你連線的後端服務

    大多數 AI 建置者都會產生一個前端並給你一份清單:在這裡註冊一個資料庫,在那裡註冊一個身分驗證提供者,貼上金鑰,編寫膠水。該堆疊中的每個接縫都由你負責維護。 Kliv 的後端與應用程式一起誕生 — 一個系統,因此建置頁面的相同對話也會編寫你的遷移和存取規則,並且這些規則無處不在。

    每個應用程式與生俱來的

    這不是你逐一啟用的功能清單。它是每個 Kliv 應用程式下的標準裝置 — 這是在你完成第一頁描述之前執行的內容。

    01

    擁有自己規則的資料庫

    你的資料儲存在你自己的資料庫中,並且在行中強制執行隱私:像「客戶只讀取自己的專案」這樣的規則是資料的屬性,在每個查詢上進行檢查 — 而不是某人必須記住在每個頁面中寫入的 if 語句。

    02

    登入和身分

    帳戶、會話、角色和組織在你的首頁出現之前就已經存在。你的使用者可以是個人,也可以是整個公司,並且登入遠遠超出了密碼的範圍,密碼在下面有自己的部分。

    03

    具有存取規則的檔案儲存

    上傳、影像和檔案都有自己的規則:私人的、每個組織共享的或購買後的限制。轉發的連結不會開啟規則不允許的任何內容 — 共享是一個決定,而不是 URL 的意外。

    04

    伺服器端函式,型別化

    當邏輯必須在伺服器上執行時(計算、回呼到另一個工具、夜間作業),AI 會根據編譯器檢查的型別化 SDK 編寫真正的 TypeScript。函式按需、按事件或按方案執行。

    05

    金庫裡的秘密

    API 金鑰和憑證位於保管庫中,永遠不會存在於瀏覽器可以看到的程式碼中。函式在執行時讀取它們,並且任何敏感內容都不會出現在你的原始程式碼中。

    06

    帶有你名字的電子郵件

    傳遞和範本是後端的一部分 — 你的應用程式傳送的郵件被標記為你的應用程式,編寫一次,無需配置第三方郵件服務即可傳送。

    07

    在建置時進行管理

    沒有後端服務的部分:AI 將所有這些作為建置的副作用來維護。描述一個功能,架構更改以有序、追蹤的遷移的形式出現;存取規則隨著需要它們的頁面而變化。後端跟隨應用程式,因為它們從未分開。

    標準配備

    六個部件,一個系統-每個部件都已經連線到其他部件。

    你自己的資料庫

    對每個查詢強制執行行級安全性 — 每個使用者的隱私是資料的屬性,而不是程式碼必須保持的習慣。

    登入和身分

    帳戶、組織和角色 — 以及 Google 和 Facebook 登入、金鑰和使用者的雙重因素。

    檔案儲存

    有自己的存取規則的檔案 — 私有的、每個組織的或購買後的檔案。僅靠連結什麼也打不開。

    型別化伺服器端函式

    Real TypeScript 針對經過編譯器檢查的 SDK — 按需、按事件或按計畫。

    秘密金庫

    程式碼和瀏覽器中的金鑰和憑證 — 函式在執行時讀取它們。

    電子郵件傳送

    內建範本和交付 — 郵件帶有你的應用程式名稱,而不是供應商的名稱。

    登入,內建

    大多數建置者都會向你提供電子郵件和密碼,並將其稱為身分。 Kliv 為你的應用程式的使用者提供他們期望從真實產品中獲得的登入體驗,並且它屬於你的應用程式:你的流程、你的品牌、你的記錄。

    電子郵件和密碼

    帳戶、驗證和重置——賭注,處理得當。

    使用 Google 和 Facebook 登入

    使用使用者已有的帳號一鍵登入。

    萬能鑰匙

    使用面容 ID、觸控 ID 或安全性金鑰進行防網路釣魚登入 — 無需竊取密碼。

    雙重身份驗證

    來自任何身份驗證器應用程式的 TOTP 程式碼,適用於想要第二把門鎖的使用者。

    組織和角色

    團隊、角色和組織牆——資料庫規則所依據的結構。

    你的使用者,你的記錄

    每個帳戶都是你自己的資料庫中的一行——對它們進行分段、匯出或根據請求刪除它們。關係是你的。

    常見問題

    後端是我必須管理的單獨服務嗎?

    不——這就是重點。它與應用程式一起誕生,並透過建置它的相同對話進行管理。無需配置儀表板,無需在第一天貼上金鑰,也不會出現與你的程式碼不同步的第二個系統。

    誰寫資料庫遷移?

    AI 確實如此,這是建置的副作用。描述該功能,架構變更以有序、追蹤的遷移的形式出現 — 如果你想檢視,則可以閱讀,按順序應用,以便資料庫的歷史記錄與應用程式的歷史記錄一樣清晰。

    每個使用者的隱私實際上是如何執行的?

    在行。每個查詢僅傳回允許登入使用者檢視的內容,因為規則存在於資料本身上 — 因此頁面中的錯誤不會洩漏資料庫拒絕移交的內容。

    我的使用者可以使用 Google 登入嗎?

    是的 — Google 和 Facebook,以及金鑰和 TOTP 二因子。這是你應用程式的登入,而不是第三方小工具:你的流程、你的品牌和使用者記錄都儲存在你自己的資料庫中。

    API 金鑰和憑證位於哪裡?

    在金庫裡。函式在執行時讀取它們;它們永遠不會出現在瀏覽器可以看到的程式碼中,並且你的來源歷史記錄中不會出現任何敏感內容。

    我可以取出我的程式碼和資料嗎?

    是的。你的應用程式的原始程式碼可以雙向同步到你自己的 Git 儲存庫,並且資料是你自己的資料庫 — 隨時匯出。 Kliv 的賭注是你留下來是因為它很好,而不是因為離開很難。

    描述你的應用程式。後端隨之而來。

    內建意味著建在一起:結帳、智能體和測試都在同一個後端上執行——一組規則,在任何地方強制執行。

    價格