Ang iyong infrastructure. Ang iyong data. Ang iyong mga key.
Ginawa ang Cronable para tumakbo tulad ng isang pinagkakatiwalaang bahagi ng sarili mong stack. Narito nang eksakto kung paano nito pinapanatili ang iyong automation, secrets at history sa ilalim ng iyong kontrol.
On-premises ayon sa disenyo
Nag-i-install ang Cronable sa sarili mong makina — isang Mac o Windows desktop app, o isang server sa ilalim ng systemd/launchd. Walang SaaS tier at walang cloud dependency. Ang mga routine na outbound call nito ay isang pana-panahong pagsusuri ng licence — na nagkukumpirma sa iyong subscription at nag-uulat ng simpleng bilang ng job at user — at isang pagsusuri para sa mga bagong signed release; at, tanging kung ino-on mo ang mga ito, isang outbound na koneksyon sa hosted relay ng Cronable para sa mga inbound webhook o remote control. Ang iyong workload — mga job definition, secret, run at output — ay nananatili sa makina at hindi kailanman ipinapadala sa amin. Ang tanging eksepsyon ay isang aktibong remote-control session: ang dashboard traffic nito ay dumadaan sa aming edge (kaparehong tiwala tulad ng anumang hosted proxy), na may end-to-end encryption papunta sa sarili mong makina bilang isang planadong Enterprise option.
Secrets at credentials na encrypted at rest
Ang mga secret value ay AES-256-GCM encrypted gamit ang isang key na hinango mula sa sarili mong encryption key (scrypt na may per-install na random salt). Ang mga typed credential — API keys, bearer tokens, basic auth, custom headers at Postgres connection strings — ay nananahan sa parehong encrypted store at tinutukoy sa pamamagitan ng pangalan, hindi kailanman idinidikit sa mga job file. Walang isinusulat sa git, at walang umaalis sa iyong makina. Ikaw ang nagba-backup ng key nang hiwalay — mawala ito at hindi na mababawi ang mga secret ayon sa disenyo.
Naka-mask sa bawat log at stream
Ang mga na-resolve na secret at credential value ay tinatanggal at pinapalitan ng “***” sa mga log file, job output at ang live log stream — kahit pa hinati ang isang value sa mga streaming chunk. Ang tumatakbo sa iyong makina ay nananatili sa iyong makina.
Authenticated at least-privilege
Ang web console ay nangangailangan ng per-user na mga login na may argon2id password hashing at brute-force lockout. Nagbi-bind ang engine sa localhost bilang default at nilalayong tumakbo bilang isang dedikadong low-privilege na user. Ang mga server-to-server na caller ay gumagamit ng isang pribadong bearer token; ang mga browser ay gumagamit ng isang short-lived na session cookie — at ang pag-log out, o pag-expire ng isang session, ay nagsasara maging sa mga bukas na live-log stream sa loob ng ilang segundo. Ang mga password ay dapat ding pumasa sa isang strength check — isang pinakamababang haba kasama ang isang guessability test — kaya tinatanggihan ang mahina o madaling mahulaang mga ito. Ang optional na two-factor authentication (TOTP) ay nagdaragdag ng isang one-time code mula sa isang authenticator app tulad ng Google Authenticator, na may mga recovery code para sa isang nawalang device; kinakailangan ito para gumamit ng remote access, kaya ang isang makina ay maibubukas lamang sa hosted dashboard ng isang operator na may naka-enable nito.
Team access na may mga role
Ang web console ay multi-user, na may apat na nakahanay na role — viewer (read-only), editor (gumagawa ng mga job, secret at run), admin (namamahala ng mga user, role at setting), at owner, ang unang account ng install. Ang mga admin ay nagdaragdag at nag-aalis ng mga user, nagtatakda ng role ng bawat tao, nagre-reset ng isang password o two-factor device, at nagbabawi ng access sa ilalim ng Settings → Users — kaya ang isang umaalis na kasamahan ay agad na nawawalan ng access at walang nagbabahagi ng isang login. Ang mga naka-lock down na install ay maaaring pumili ng higit pa: nililimitahan ng exec-tiering kung sino ang maaaring gumawa ng mga command-running na job, at nagdaragdag ang change-approval ng four-eyes na pagsusuri, kaya dapat aprubahan ng isang pangalawang admin ang isang naka-stage na job o secret na pagbabago bago ito magkabisa.
Single sign-on sa pamamagitan ng OIDC
Dalhin ang iyong identity provider — Okta, Entra ID, Google, Keycloak — sa pamamagitan ng OIDC authorization-code flow na may PKCE at ganap na ID-token verification. Ang mga SSO sign-in ay dapat tumugma sa isang umiiral na lokal na account: walang awtomatikong ini-provision, at ang mga error ng provider ay lumilitaw bilang mga nakapirming, magiliw na mensahe sa halip na mga raw redirect.
Isang audit trail na talagang mababasa mo
Ang mga login at nabigong pagtatangka, mga pagbabago sa secret at credential, mga edit sa job, mga update sa settings at mga git sync ay itinatala sa isang append-only na audit trail — mga pangalan at metadata lang, hindi kailanman mga value — natitingnan at filterable mismo sa console sa ilalim ng Settings → Audit.
Hardened na inbound webhooks
Ang mga inbound webhook ay umaabot sa iyong daemon sa pamamagitan ng aming license-gated na relay sa isang koneksyong binubuksan ng iyong server nang outbound, kaya hindi mo kailanman inilalantad ang isang port — maliban kung sadyang piliin mong gawin iyon. Ang bawat hook ay nakatali sa iyong license — walang ibang customer ang makaka-claim nito o makakatanggap ng mga event nito, kahit alam ang URL nito — at binabantayan ng isang per-hook token na iniimbak lamang bilang isang SHA-256 hash at sinusuri sa constant time. Ang URL ay nangangailangan ng hindi bababa sa 32 na hindi mahulaang karakter kasama ang token na iyon; ang mali, nawawala, naka-disable o hindi kilala ay pare-parehong nagbabalik ng parehong generic na 401, at ang paulit-ulit na mga probe mula sa isang IP ay pansamantalang binabawalan — kaya walang maaaring i-enumerate at walang maaaring i-brute-force. Ang mga token ay ipinapakita nang isang beses sa paggawa at maaaring i-rotate sa isang click. Kung mas gusto mong hindi na dumaan sa mga server namin ang mga papasok na payload, maaari mong laktawan ang relay at maghain ng sarili mong HTTPS endpoint — iyon ang tanging pagkakataong talagang nagbubukas ka ng port, at diretso nang dumarating ang mga webhook sa iyong makina.
Git-audited, reversible na history
Ang bawat job definition ay isang file sa isang git repository na pag-aari mo. Ang bawat pagbabago ay isang commit — ganap na diffable, maiuugnay sa may-gawa at maibabalik. Ang iyong job history ay ma-audit gamit ang mga tool na ginagamit na ng iyong team. Kapag nag-link ka ng isang repository para sa two-way sync, isang pribado lamang ang tinatanggap ng Cronable — tinatanggihan nito ang isang public na repo, at hihinto sa pag-sync kung ang isang naka-link na repo ay ginawang public sa bandang huli — kaya ang iyong mga job definition ay hindi kailanman magiging world-readable.
Tapat tungkol sa trust boundary
Ang trabaho ng Cronable ay magpatakbo ng mga command, AI agent at HTTP para sa iyo, kaya ituring itong tulad ng isang shell sa makina. Ang mga expression ay tumatakbo sa isang footgun-guard na sandbox, hindi isang hardened na boundary — huwag kailanman itong pakainin ng untrusted na input. Tinutulungan ka naming i-deploy ito nang may least privilege at makatwirang network isolation.
Patakbuhin ito sa likod ng iyong firewall.
May mga security requirement na kailangang matugunan? Sabihin sa amin ang iyong environment at sabay nating dadaanan ang deployment, hardening at access controls.
Cronable, at hindi ito kailanman umaalis sa iyong makina.