LEARN · ARTICLE
把小工具做成 Apify Actor 上架
作者：Rock Lee 實測日期：2026-11-09（Asia/Taipei）；雲端成本數字取自 2026-10-02 的實跑紀錄
為什麼寫這篇
寫完一支小工具，很多人第一個念頭是「包成 API 賣」。可是自己架主機、接金流、處理排隊，雜事比工具本身還多。Apify Store 的賣點是：你把程式包成 Actor，平台負責執行、計量和收費，你只要決定「哪個動作收多少錢」。
我們實際上架了二十幾支 Actor，這篇用其中一支 batch-image-compress（把一批圖片網址轉成 WebP／JPEG／PNG，可順便移除 EXIF）當例子，從本機測試、計費設定一路寫到上架。最後也會老實交代：技術上做得出來，而且成本很低，但「上架」跟「有人付錢」是兩回事。
實測環境
| 項目 | 實測值 |
|---|---|
| 範例 Actor | batch-image-compress（AGPL-3.0 開源） |
| 語言 | Python 3.13.5 |
| 主要套件 | apify SDK 4.0.2、httpx 0.28.1、Pillow 11.2.1 |
| 命令列工具 | Apify CLI 1.10.0（Node.js 24） |
| 本機系統 | Linux |
| 計費模式 | 按事件計費（Pay per event） |
步驟
1. 先把設定檔寫清楚
Actor 的身分證是專案裡的 .actor/actor.json。我們這支設定預設記憶體 512 MB、上限 2048 MB、逾時 3600 秒，分類填三個：開發者工具、AI、自動化。
記憶體不要隨手開大。雲端用量跟記憶體大小和執行時間都有關，圖片壓縮這種小活，512 MB 就很夠（下面的實測峰值只有 76～164 MB）。
2. 準備一份「故意放壞網址」的測試輸入
測試輸入放三個網址：兩張公開的測試圖，再加一個一定會回 404 的網址。故意放一個壞的，是為了確認兩件事：程式不會因為一張圖壞掉就整批中斷，以及失敗的那筆不會被收錢。
3. 在本機跑一次，順便模擬計費
apify run -p --entrypoint src --input-file test-inputs/smoke.json
我們把這行包進一個小腳本，跑之前先設好「模擬計費」用的環境變數，讓本機也能算出「如果在雲端，這次要收多少」。結果：
- 3 筆處理完：成功 2、失敗 1（就是那個 404）
- 峰值記憶體 76 MB，圖片處理本身 0.3 秒
- 模擬收費：成功轉檔 2 次 × US$0.002 = US$0.004，失敗那筆 0 元
- 第一次執行要建虛擬環境、裝套件，整個指令約 9.6 秒
4. 打開輸出，逐欄確認
每處理一張圖，資料集裡就多一列。成功的那列記錄了轉檔前後大小：JPEG 35,588 bytes 轉成 WebP 剩 17,688 bytes，省 50.3%，尺寸 239×178 不變，EXIF 已移除。失敗的那列只有 HTTP 404 這個錯誤訊息，沒有任何收費事件。
只用別人的測試圖不夠，我又拿自己畫的兩張圖，從本機的小型網頁伺服器餵給它跑一次：
- PNG 2000×1125：57,854 → 30,636 bytes，省 47.05%
- JPEG 2400×1040：316,159 → 67,798 bytes，省 78.56%
- 圖變大，峰值記憶體升到 164 MB，仍遠低於 512 MB
5. 設計計費：只對「做成功的事」收錢
計費事件寫在 .actor/pay_per_event.json：
| 事件 | 價格 | 什麼時候收 |
|---|---|---|
| Actor 啟動 | US$0.001／GB（至少算 1 GB） | 每次執行一次 |
| 成功轉檔 | US$0.002 | 每張成功存檔的圖 |
| 只移除 EXIF | US$0.001 | 開啟「只清資料」模式時 |
失敗、不是圖片、檔案過大、重複的圖，預設都不收。另外我們刪掉了平台預設的「每寫一列資料就收費」事件，避免失敗列也被算錢。
訂價前我們在雲端實跑過：2026-10-02 一批 12 張（成功 10 張），平台用量 US$0.000867，平均每張約 US$0.0000867，這批平均省 31.8%。也就是說，成本跟售價差了一個數量級以上，訂價不是問題。
6. 推上雲端、先私人，確認後再公開
我們的固定順序是：
apify push推上雲端，先維持私人- 在雲端跑幾次小測試，看實際用量
- 補齊說明、範例輸入、分類
- 確認無誤，才把 Actor 設成公開
- 原始碼另外公開在 GitHub（AGPL-3.0），推上去前先掃一次有沒有金鑰或個資
公開後，Store 頁面會顯示價格、說明、使用人數與評分；GitHub 那邊則是完整原始碼。
結果
上架本身沒有難度，難的是之後。我們用 Apify 的公開 API（不用金鑰）查 batch-image-compress，2026-11-09 16:59 的數字是：累計執行 42 次、累計使用者 2 人、評論 0 則；近 30 天公開執行 29 次，全部成功。同一個帳號在 Store 上公開的 Actor 共 24 支。
更早在 2026-10-21，我們把當時 26 支 Actor 全查了一遍：每支累計使用者都只有 1～2 人；近 30 天每支約 13～20 次執行，幾乎都來自同一個不是我們的帳號，次數平均分布在所有 Actor 上。這比較像平台的自動測試，不像真的客戶（API 不揭露使用者身分，所以只能推測）。其中 website-change-monitor 近 30 天 17 次全部失敗，這種成功／失敗次數任何人用公開 API 都查得到，很傷信任度。
收益方面，截至 10/28 的檢查，我們的本機紀錄和信箱都沒有任何 Apify 收益或撥款通知；確切數字要登入後台才看得到，這篇不寫沒看到的數字。
踩坑紀錄
- 一天只能公開 5 支。 第 6 支會回 HTTP 429
daily-publication-limit-exceeded，訊息寫明 24 小時後再試。我們撞到兩次，都是當下停手、之後再公開，沒有重試硬衝。 - 分類最多 3 個。 填 4 個（多加一個開源分類）會回 HTTP 400。
- 說明文字有長度上限。 簡介太長會被格式檢查擋下，我們的紀錄是 300 字元，送出前先數字數。
- 剛公開時頁面可能還是 404。 公開前那個 404 會被快取一段時間（快取設定 30 分鐘），文字版頁面先通，網頁版晚一點才出現。不用急著重送。
- 範例輸入別留假資料。 範本自帶的
helloWorld之類的欄位要刪乾淨，換成真的能跑的範例，不然使用者第一次試用就失敗。 - 失敗紀錄查得到。 近 30 天的成功／失敗次數在公開 API 裡就有。上架前要確定預設輸入真的跑得成功。
常見問題
Q1：使用者丟了壞網址，會被扣錢嗎？ 照我們的設定不會。只有「成功轉檔」或「成功清 EXIF」才觸發收費事件，404、非圖片、過大、重複都免費，本機模擬也證實失敗那筆是 0 元。
Q2：本機跑和雲端跑結果會一樣嗎？ 處理邏輯一樣，但本機的金額是模擬的。雲端的實際平台用量要看執行紀錄，我們的訂價就是用雲端實跑數字算的。
Q3：Store 上的使用人數可以當成客戶數嗎？ 不行。我們的經驗是，每支剛上架的 Actor 幾乎都有一個固定帳號定期來跑，看起來是平台測試。要看有沒有人付錢，請看後台的收益頁。
Q4：值得做嗎？ 當作練習「把工具產品化」很值得：設定、計費、開源、文件一次走完，成本也低。當作收入來源，我們目前還沒有證據證明它有效。選題要先找「有人在搜、現有工具做不好」的缺口，而不是先做再說。
複製這段給你的 AI agent
目標：在本機替一個現成的 Apify Actor 專案做「上架前檢查」，只讀與本機執行，不部署、不公開。 前提與禁止事項： - 不要讀取、印出或寫入任何 API token、密碼或 .env 內容。 - 不要執行 apify push、apify login、或任何把 Actor 設為公開的指令。 - 不要付款、不要升級方案、不要對外發布或寄信。 - 不要刪除專案以外的檔案。 步驟： 1. 讀 .actor/actor.json，回報：預設記憶體、上限、逾時、分類數量（超過 3 個要標紅）、description 字元數（超過 300 要標紅）。 2. 讀 .actor/input_schema.json，列出 prefill／example 值；有 helloWorld 或明顯假資料就標出來。 3. 讀 .actor/pay_per_event.json（若有），列出每個事件與價格；確認沒有 apify-default-dataset-item 收費事件。 4. 準備一份測試輸入：2 個正常的公開測試網址＋1 個必定 404 的網址。 5. 在本機執行：apify run -p --input-file <測試輸入>，回報成功數、失敗數、峰值記憶體、執行時間。 6. 確認失敗那筆沒有觸發收費事件。 驗收：附上上述數字與每項檢查的「通過／不通過」，不附任何金鑰字串。