Lark /

larksuite.com · Netdisk and pan, Storage · 2 records · JSON

Lark / 飞书 Drive via multi-tenant app credentials (the FeiSync pattern) Netdisk and pancaveatemailno cardphoneRper-object-cap
Lark (Feishu) Starter - free plan Storagecaveatemail?card?Rper-object-cap

Lark / 飞书 Drive via multi-tenant app credentials (the FeiSync pattern) Netdisk and pan

caveatemailno cardphoneRper-object-cap

open.larksuite.com/app · platform storage reached through app credentials · netdisk-pan/lark-drive-via-multi-tenant-app-credentials · JSON · compare

Free tier	100 GB per Lark tenant. '任意扩容，只要添加 App ID 和 App Secret 就可以免费获得100G空间，单文件250M，简单说就是容量上限取决于你的号数量' unit GiB; metered on stored-bytes
Price	none stated
Per-object cap	250 MB per file (250000000 bytes)
Retention	While the tenant persists. No retention clock published
Egress	Unmetered in practice; there is no egress line item on the free tier
Identity	email a distinct email address or phone number per tenant. Lark has historically required an overseas IP to register outside the mainland, which is a feature here
Limits	per-object-cap 250 MB per file source request-rate apps inside one tenant share that tenant's 100 GB, so a second app is not a second quota source
Binding	per-object-cap 100 GB per tenant multiplies cleanly and the traffic is free, so the only number that shapes a plan is 250 MB per file: the 20 TiB archive becomes 84,000 objects, and the 10 TiB working set 42,000.
Interface	rest
Tooling	FeiSync v1.0.0 by fish2018, Tauri and Rust with a Vue front end, presented on linux.do on 2025-12-28: multi-tenant routing, one-way or two-way cron sync, resumable transfer and an open HTTP API. The underlying API is the Lark Drive open platform v1 at /drive/v1/files
Composes with	This is the Google service-account pattern reimplemented for Lark: create N free tenants, register a custom app in each, and FeiSync load-balances writes across them for 100 GB times N in one flat namespace. 250 MB per file is the binding number, not the bytes
Reliability	Two constraints bite: 250 MB per file caps the cold-archive case hard, and app-permission changes break the wrapper. Tenant creation needs a distinct identity each time
Notes	The most directly applicable of the app-credential patterns, because tenancy is free and self-service. The 250 MB file cap is what makes it a shard target rather than a store, and that is a job for a chunker rather than a blocker.
Evidence rung	reported
Checked	2026-10-21 (inherited); stale on 2026-11-04
Parsed numbers	`$.limits[0].value` limit:per-object-cap 250.0 MB `$.limits[1].value` limit:request-rate 100.0 GB

Evidence (3)

date	source	what it proved
2026-10-21	linux.do/t/topic/1371150	'免费无限扩容，每个账号免费扩容100G，单文件250M' and '不能是同一个企业的不同应用，会共享100G'
2026-10-21	linux.do/t/topic/360439	'larksuite所谓飞书海外版，必须要海外IP才能注册' '海外ip，会成功'
2026-10-21	linux.do/t/topic/588707	'Lark 免费用户就有自定域名邮箱、100 GB 存储'

More fields (6)

{
 "access_mode": "registration-gated",
 "wrapper": "FeiSync v1.0.0 (fish2018)",
 "quota_per_tenant_bytes_derived": 107374182400,
 "per_file_cap_bytes_derived": 250000000,
 "overseas_ip_required": true,
 "aliases": [
  "Lark / 飞书 Drive via multi-tenant app credentials (FeiSync pattern)"
 ]
}

Lark (Feishu) Starter - free plan Storage

caveatemail?card?Rper-object-cap

www.larksuite.com · paas · storage/lark-starter-free-plan · JSON · compare

Free tier	100 GB total storage per organization on Starter (Free); 250 MB single-file limit for Docs uploads on Starter unit GB; metered on stored-bytes
Price	none stated
Per-object cap	250 MB per file (250000000 bytes)
Retention	not stated
Egress	Downloads served from Lark CDN (ByteDance edge) at no metered charge; download via OpenAPI media download returns a signed URL, no per-GB line item anywhere in the plan table
Identity	email (placeholder) not published
Limits	per-object-cap 250 MB per file source 250 MB per file for Docs on Starter (vs 50 GB on Pro); upload_all hard-caps at 20 MB by design, must use multipart; 5 QPS on upload_all; 4 MB fixed chunk size on multipart; upload transaction ID valid 1 day for resume
Binding	per-object-cap the per-object cap sets the shard size and therefore the object count; it bounds the total more tightly than any headline quota
Interface	rest, rclone, cli rest
Tooling	Official OpenAPI v3 drive endpoints (upload_all for <=20MB, multipart upload of 4MB chunks above that) + first-party CLI larksuite/cli (17,762 stars, pushed 2026-10-21) with `lark-cli drive +upload`; no rclone backend
Composes with	100 GB x N free organizations. Starter is self-serve per organization and the quota is per-org, not per-user, so N disposable orgs = N x 100 GB. Paid Basic (5 TB) shows the ceiling is only billing, not architecture.
Reliability	Rate limits are explicit (5 QPS on single upload) and multipart is resumable, but Starter orgs that lapse back from a paid plan are force-collapsed to Starter member and storage caps - data above 100 GB becomes unwritable, not deleted.
Notes	100 GB total storage per organization on Starter (Free); 250 MB single-file limit for Docs uploads on Starter
Evidence rung	reported One page read moves it to documented.
Checked	2026-10-21 (inherited); stale on 2026-11-04
Parsed numbers	`$.limits[0].value` limit:per-object-cap 250.0 MB

Evidence (3)

date	source	what it proved
2026-10-21	www.larksuite.com/hc/en-US/articles/497171699982-overview-of	table row: 'Total storage space \| 100 GB \| 5 TB \| 15 TB \| 15 TB + 30 GB x purchased seats'; 'Single file upload limit for Docs \| 250 MB'
2026-10-21	open.larksuite.com/document/uAjLw4CM/ukTMukTMukTM/reference/	'please do not use this interface to upload files larger than 20MB... use the multipart upload interface', supports 5QPS
2026-10-21	open.larksuite.com/open-apis/auth/v3/tenant_access_token/int	not published

Unknown or withheld values (7)

$.evidence[2].proved withheld
$.free_tier.notes process
$.identity_cost.detail defaulted
$.identity_cost.kind identity-defaulted
$.per_object_cap.notes not-extracted
$.retention.notes not-extracted
$.retention.stated not-extracted