Mga koponan at access

Bigyan ang bawat tao sa iyong koponan ng eksaktong access na kailangan nila

Apat na tungkulin ng customer, mga sub-account na sumasalamin sa kung paano talaga nakabalangkas ang iyong negosyo, mga API key sa bawat organisasyon, single sign-on, at isang audit log sa likod ng bawat pribilehiyadong aksyon. Ang parehong modelo ng pag-access ay tumatakbo sa dashboard, API, CLI, Terraform, at sa aming MCP server. Availability: ang Terraform provider ay aktibong ginagawa pa at hindi pa available. Lahat ng iba pang inilarawan dito ay live na ngayon.

Magsimula nang libre Tingnan ang hosting ng ahensya

650,000+mga site na naka-host sa buong mundo
4mga papel ng customer, nakatalaga na at handa na
35mga granular na key ng pahintulot
14 na arawlibreng pagsubok sa card

Apat na tungkulin, iginuhit kung saan talagang naghahati ang gawain

Ang access ay hindi iisang on/off switch. Ang bawat organisasyon ng customer ay may kasamang apat na mga gampanin, na ang bawat isa ay nakapirming grupo ng mga granular na pahintulot ng module.action — kaya ang isang contact sa pananalapi ay hindi kailanman hahawak sa isang server at ang isang developer ay hindi kailanman makakakita ng isang invoice.

May-ari

Buong kontrol sa organisasyon at sa mga sub-account nito: paglikha ng mga organisasyon ng anak, pag-aanyaya at pag-aalis ng mga miyembro, pagpapalit ng mga tungkulin, pamamahala sa mga API key, paglalaan, pag-restart, pagsuspinde at pag-delete ng mga site, pamamahala sa mga invoice at paraan ng pagbabayad, at pagbabasa ng audit log. May dalawang bagay na sadyang nasa labas nito — ang pagsasara ng isang organisasyon at paglalabas ng mga refund ay mga aksyon ng kawani, hindi tungkulin ng customer.

Tagapamahala ng Pagsingil

Lahat ng nauukol sa pananalapi at wala nang iba pa: mga invoice, subscription, paraan ng pagbabayad, at ang katalogo ng plan, kasama ang pagtingin sa organisasyon at sa listahan ng mga miyembro nito. Walang anumang access sa site — ang isang contact sa pananalapi o panlabas na tagapagtala (bookkeeper) ay hindi maaaring mag-restart, mag-suspend, o mag-delete ng anuman.

Nag-develop

Magtrabaho sa mga site nang walang hawak na pera: tingnan at i-provision ang mga site, i-restart ang mga serbisyo, i-purge ang mga cache, pamahalaan ang mga API key, at mag-raise o sumagot sa mga support ticket. Walang view ng billing, walang pamamahala ng miyembro, walang suspend, at walang delete — ang mga mapanira at pang-komersyong aksyon ay nananatili sa may-ari.

Basahin lamang

Isang kumpletong view na walang kakayahang baguhin ang anuman — mga miyembro, site, billing, plan, ticket, status ng pagsasalin at ang audit log. Ang tamang papel para sa isang stakeholder na kliyente, internal auditor, o bagong empleyado na nagaangkop pa lang.

Mga sub-account na tumutugma sa iyong totoong istruktura

Ang tenancy ay isang tree, hindi isang flat list. Nakalagay ang isang reseller organisation sa itaas ng mga client organisation nito, at ang mga site naman ay nakalagay sa ilalim ng mga iyon. Ang isang team member ay isang membership — isang user, isang organisation, isang role — kaya ang parehong primitive ang nagpapatakbo sa isang team na may dalawang tao, isang ahensya na namamahala ng sandaang client account, at isang reseller na nagpapatakbo ng mga sub-account sa ilalim ng sarili nitong brand.

Ang mga tungkulin ay ibinibigay sa bawat organisasyon, at ang pagpapatupad ay para rin sa bawat organisasyon. Ang isang tungkulin sa isang organisasyon ay walang ibinibigay na access sa ibang hiwalay at walang kaugnayang organisasyon — ang isang contractor ay maaaring maging Developer sa isang client account at Read-only sa ikalawa, mula sa parehong login. Gayunpaman, dumadaloy pababa ang access sa sarili mong hierarchy: ang isang tungkulin sa isang parent organisation ay nailalapat sa mga organisasyong nakapailalim dito, na siyang paraan kung paano pinamamahalaan ng mga reseller at ahensya ang kanilang mga kliyente.

Ipinatutupad ang izolasyon sa database, hindi lamang sa code ng aplikasyon. Nililimitahan ng row-level security ng Postgres ang bawat query ng tenant sa subtree ng tumatawag, at ang anuman sa labas ng subtree na iyon ay nagbabalik ng not-found sa halip na error sa pahintulot — kaya hindi man lang kinukumpirma ng platform na umiiral ang organisasyon o site ng isa pang tenant.

Ang parehong mga pahintulot sa bawat ibabaw

Ang mga ginagampanan ay hindi lamang pampaswerte sa dashboard. Ang bawat paraan patungo sa platform ay tumutukoy sa parehong mga key ng pahintulot, kaya walang backdoor na lumalaktaw sa iyong mga panuntunan sa pag-access.

Dashboard

Mga site, pagsingil, tiket, abiso, notipikasyon, API key, at pamamahala ng team sa isang shell. Ipinapakita ng interface kung ano ang pinapayagan ng tungkulin ng naka-sign in na miyembro, kaya hindi ipinapakita sa mga tao ang mga kontrol na hindi nila magagamit.

Pampublikong API at CLI

Ang nai-publish na API ay ang parehong engine API na ginagamit ng dashboard. Ang mga API key ay ibinibigay sa bawat organisasyon na may mga granular scope na nakaugnay sa mga pahintulot ng RBAC, at ang magkahiwalay na sandbox at live mode ay nangangahulugang maaari mong subukan ang mga integration nang hindi ginagalaw ang totoong pagsingil o provisioning.

Provider ng Terraform

Pamahalaan ang mga site, domain, DNS, mailbox, at plano bilang infrastructure-as-code at patakbuhin ang terraform apply para mag-provision ng hosting — na pinamamahalaan ng parehong mga scope tulad ng iba pa.

Server ng MCP

Ikonekta ang Claude Code, Cursor, ChatGPT, Claude Desktop o anumang tool na may kakayahang MCP. Ang mga token ay naka-scope sa isang organisasyon at sa mga pahintulot nitong RBAC, maaaring bawiin kada tool, may kumpirmasyon sa mga mapanirang aksyon, mga cap sa paggastos, at buong audit trail.

Pamamahala ng Susi

Ang hash lang ng bawat API key ang nakaimbak — hindi kailanman ang mismong raw key. Mayroon silang pangalan at nakikitang prefix para mapag-iba mo ang mga ito, maitala kung kailan huling ginamit, at maaaring bawiin nang paisa-isa nang hindi naaapektuhan ang iba.

Isang pag-log in, nakabatay sa mga pamantayan, sa lahat ng bagay

Ang Identity ay pinatatakbo ng Keycloak, kaya ang authentication ay wastong OIDC at SAML sa halip na isang sariling gawang login form na idinikit lamang sa isang hosting panel.

Mag-log in gamit ang magic-link na email bilang default, na may email at password bilang pamalit para sa mga mas gustong gamitin iyon.
Ang mga Passkey at WebAuthn para sa pag-sign-in na lumalaban sa phishing, pati na rin ang TOTP dalawang-salik na pagpapatotoo na ipinapatupad para sa lahat ayon sa patakaran.
Panloob na pag-log in sa pamamagitan ng Google, Microsoft, GitHub at iba pang tagapagbigay ng pagkakakilanlan.
SAML single sign-on para sa mga customer ng enterprise at agency, kaya ang access ng team ay sumusunod sa iyong kasalukuyang direktoryo.
Isang sesyon lang sa dashboard, console ng admin, pampublikong site at knowledge base, at mga ticket sa suporta — mag-sign in nang isang beses, hindi limang beses.
Bine-validate ang bawat signup email bago ginagawa ang isang account, kaya ang mga hindi naihahatid at invalid na address ay hindi kailanman nakakapasok sa iyong team.
Dahil ito ay nakabatay sa mga pamantayan, ang mismong tagapagbigay ng pagkakakilanlan ay maaaring palitan nang hindi na muling isinasaayos ang anuman sa paligid nito — ang parehong patakarang walang pagkakakulong na inilalapat namin sa bawat iba pang vendor.

Pananagutan na maipagkakatiwala mo sa isang auditor

Ang bawat privileged action ay sumusulat ng append-only audit record: kung sino ang gumawa nito, kung ano ang ginawa nila, kung kanino nila ito ginawa, ang supporting evidence, at ang nagmula o originating IP address. Ang log ay append-only — ang mga event ay idinagdag at hindi ini-edit sa datihan — at sa production, ito ay naka-time-partition kaya nananatili itong mabilis habang lumalaki ito.

Ang pagbasa sa log na iyon ay isang pahintulot na rin. Hawak ito ng mga may-ari at mga miyembrong read-only, kaya makikita ng taong responsable sa account at ng taong nag-a-audit dito ang buong kasaysayan nang hindi nangangailangan ng mas mataas na karapatan para gawin ito.

Nakapaligid dito ang mga kontrol na hinihiling ng mas malalaking team: mga patakaran sa sesyon, opsyonal na mga IP allowlist sa bawat organisasyon, at step-up authentication sa mga sensitibong aksyon upang ang live session lamang ay hindi sapat para gumawa ng isang seryosong bagay.

Paano lumalago ang mga pahintulot kasama mo

Ang katalogo ng pahintulot ay data, hindi naka-hardcode na lohiko — kaya naman maaari itong palawakin nang hindi muling binubuo ang platform.

35 na detalyadong susi ng module.action ngayon, na sumasaklaw sa mga organisasyon, miyembro, API key, site, billing, mga plano, fleet, mga tiket, customer, pang-aabuso, mga kampanya, pagsasalin, at pag-audit.
Ang katalogo ay idempotent na nilalagyan sa bawat pag-deploy, at ang balidasyon ay maingay na nabibigo kung ang isang ginagampanan ay tumutukoy sa pahintulot na hindi umiiral — ang isang typo ay hindi tahimik na makakapagbigay ng wala.
Nagdadagdag ang mga bagong kakayahan ng produkto ng kanilang mga key ng pahintulot sa catalogue bago ilabas ang endpoint, kaya hindi kailanman isinasagawa ang access control pagkatapos maging live ang isang feature.
Ang paglilimita sa iisang membership sa mga partikular na site o rehiyon ay isang nakaplanong pagpapabuti, hindi isang bagay na maaari mong i-on ngayon. Ang kasalukuyang pattern ay ilagay ang mga site na iyon sa isang child organisation at bigyan ang tao ng role doon — na nagbibigay sa iyo ng parehong paghihiwalay gamit ang tenancy tree.
Ang mga API key ay ibinibigay sa antas ng organisasyon sa halip na bawat tao, kaya ituring ang mga ito bilang mga kredensyal ng serbisyo para sa mga integrasyon at gumamit ng mga membership para sa access ng tao.

FAQ

Ano ang talagang magagawa ng bawat tungkulin?

Ang May-ari ay may ganap na kontrol sa organisasyon at sa mga sub-account nito, kabilang ang mga miyembro, API key, site, at paraan ng pagbabayad. Ang Tagapamahala ng Pagsingil ay nakakakita ng mga invoice, suskripsiyon, paraan ng pagbabayad, at mga plano, nang walang access sa site. Ang Developer ay namamahala ng mga site at API key at humahawak ng mga tiket, nang walang kontrol sa pagsingil o miyembro. Ang Read-only ay maaaring tumingin ng mga miyembro, site, pagsingil, plano, tiket, at audit log nang hindi binabago ang anuman.

Maaari ba akong magbigay ng access sa isang site lang sa isang tao?

Hindi pa ito setting sa bawat site — ang paglilimita sa iisang membership sa mga partikular na site ay isang nakaplanong pagpapahusay. Sa ngayon, makakamit mo ang parehong paghihiwalay gamit ang tenancy tree: ilagay ang mga site na iyon sa isang child organization at bigyan ang tao ng role doon. Dahil ibinibigay ang mga role sa bawat organization, ang access na iyon ay hindi nadadala sa anupaman sa iyong account.

Ang mga API key ba ay nakaugnay sa mga indibidwal na miyembro ng koponan?

Hindi — ang mga API key ay inisyu bawat organisasyon, na may mga granular scope na nakatali sa parehong mga pahintulot ng RBAC, at hiwalay na sandbox at live mode. Gamitin ang mga ito bilang mga kredensyal ng serbisyo para sa mga pagsasama, CI o Terraform, at gumamit ng mga membership para sa mga tao. Hash lang ng bawat key ang nakaimbak, itinatala ng bawat key kung kailan ito huling ginamit, at maaaring bawiin nang mag-isa ang anumang key.

Maaari bang mag-push ng mga pagbabago ang isang developer sa isang live site?

Saklaw ng tungkulin ng Developer ang pagtingin at paglalaan ng mga site, pag-restart ng mga serbisyo, pag-purge ng mga cache, pamamahala ng mga API key, at pangangasiwa ng mga tiket. Hindi ito nagdadala ng mga karapatan sa pag-publish sa isang live na site, kaya kung gusto mong makapag-promote ng mga pagbabago ang isang tao, kailangang nasa may-ari ang access na iyon. Ang mga tungkulin ay bawat organisasyon, kaya maaari kang humawak ng ibang tungkulin sa ibang account.

Sinusuportahan ba ninyo ang SSO para sa direktoryo ng aming kumpanya?

Oo. Ang Identity ay tumatakbo sa Keycloak na may OIDC at SAML, kaya available ang SAML single sign-on para sa mga customer ng enterprise at agency kasama ang magic-link login, email at password, mga social provider, passkeys, at TOTP two-factor authentication, na ipinapatupad ng patakaran. Sinasaklaw ng isang session ang dashboard, ang pampublikong site at knowledge base, at ang mga support ticket.

Paano ko malalaman kung sino ang nagbago ng isang bagay?

Ang bawat privileged action ay isinusulat sa isang append-only audit log na nagtatala ng aktor, ng aksyon, ng target, ng sumusuportang ebidensya at ng IP address. Ang pagbabasa nito ay isang pahintulot sa sarili nitong karapatan, na hawak ng parehong mga tungkulin na Owner at Read-only, kaya maaaring suriin ng isang may-ari ng account at ng isang auditor ang parehong kasaysayan.

Binabago ba ng pagdaragdag ng mga miyembro ng koponan ang binabayaran ko?

Ang mga plano ay presyohan ayon sa kapasidad ng pag-host sa halip na sa mga tao. Sa linya ng Footprint-Free, halimbawa, ang lahat ng 42 na tier ay nagbabahagi ng eksaktong parehong set ng karapatan at nagkakaiba lamang sa bilang ng mga site na pinapayagan nila. Ang pagpepresyo ay palaging ipinapakita mula sa live na katalogo, sa iyong pera, kaya kung ano ang makikita mo sa pahina ng pagpepresyo ay ang aktwal na sinisingil.

Maaari ba akong sumubok bago pumirma?

Oo. Ang Footprint-Free na pagsubok ay tumatagal nang 14 na araw, hindi nangangailangan ng mga detalye ng card, at sumasaklaw sa hanggang 5 site, kaya maaari mong i-set up ang iyong organisasyon, imbitahan ang iyong koponan, at subukan ang mga tungkulin sa totoong gawain bago ka magbayad ng anuman. Mayroong 30-araw na garantiya sa pagbabalik ng pera para sa mga bayarang plano.

Kaugnay

I-set up ang iyong team sa loob ng ilang minuto, hindi mga tiket

Magsimula ng 14-araw na pagsubok na walang kailangang credit card sa Footprint-Free line, imbitahan ang iyong team, at tingnan ang mga role na gumagana sa mga totoong site bago ka magbayad ng anuman.

Magsimula nang libre