AList's common driver settings state that when proxy is enabled without another proxy URL, the local machine transfers the file. This can move bottlenecks to server network, CPU and I/O.
Users proxying cloud files instead of returning direct links.Wymagania sprzętowe AList: procesor, pamięć RAM, ruch WebDAV i proxy
Poznaj wymagania AList dotyczące procesora, pamięci RAM, bazy danych, WebDAV, lokalnego serwera proxy i przesyłania plików, a następnie wybierz odpowiedni sprzęt z systemem ZimaOS.
AList requirements at a glance
AList does not publish a numerical CPU or RAM minimum. The Go-based file-list/WebDAV service is lightweight when it mainly lists cloud storage and returns direct download URLs, but the ZimaOS host can become part of the data path when local proxy, WebDAV proxy, uploads, offline downloads or search indexing are enabled.
- CPU
- No numerical official minimum. Normal listing/authentication/API work is light; CPU and system work rise with proxied file transfers, indexing, archive operations and offline-download helpers.
- RAM
- No numerical official minimum. Large uploads and proxy/cache paths can create temporary memory pressure, although recent releases include streaming improvements intended to avoid buffering whole upload parts in memory.
- Storage
- Persist `/opt/alist/data` in Docker. Search indexes, database state, logs and offline-download/temp files are separate from remote cloud-drive capacity.
- Database/search
- SQLite is usable for normal AList state, but official search documentation says SQLite does not provide full-text search; other supported databases can be used when full-text indexing is needed.
- Network
- Direct-link workloads can bypass the server for file data. When local proxy is enabled, AList explicitly uses the local machine for transfer, so host LAN/WAN throughput becomes part of the workload.
- Best Zima starting point
- ZimaBoard 2 832 is an excellent AList control-plane/WebDAV starting point. Choose 1664 or ZimaCube when AList is proxying large files, doing offline downloads or serving as part of a multi-drive Productivity/storage server.
From official requirements to the right setup
AList sizing begins with one question: does file data bypass the server, or pass through it?
-
Official requirements
Identify each storage driver's download strategy. When AList can return a direct provider URL, the host mostly handles authentication/listing/control traffic; with local proxy, the host relays the actual file bytes.
-
Confirm your needs
Account for WebDAV and uploads. WebDAV proxying and large upload flows can make the ZimaOS server handle sustained network traffic and temporary buffering/cache behavior that is absent from simple file listing.
-
Leave room to grow
Choose database/search behavior. SQLite keeps a simple deployment, but AList's search documentation says full-text search is unavailable with SQLite, so larger searchable indexes can add another database service and indexing workload.
-
Run it on ZimaOS
Install AList from the ZimaOS App Store, test a real large download/upload and search/offline-download job, then monitor CPU, memory, temporary disk and network throughput before upgrading hardware.
Check every playback client
- Number and type of mounted storage providers
- Direct link versus local proxy mode
- WebDAV use
- Large upload/download concurrency
- SQLite versus other database
- Search index and full-text search requirements
- Offline-download temporary folder
- Local disk storage and other ZimaOS services
Official minimum requirements
AList's current documentation covers Docker, platform binaries, database/search and proxy behavior but does not publish a numerical CPU or RAM minimum.
Do not turn a community 'very lightweight' comment into a fixed 128 MB or 512 MB requirement. AList can be extremely light as a control plane, yet become network/I/O intensive when the host proxies or processes large file transfers.
| Requirement | Official minimum | What this supports |
|---|---|---|
| CPU | No numerical minimum published | Workload changes substantially between direct-link listing and server-proxied file traffic. |
| RAM | No numerical minimum published | Large upload/proxy/cache operations can temporarily use more memory. |
| Docker persistent path | /opt/alist/data | Official Docker example mounts persistent application data here. |
| Default port | 5244 | Current manual/Docker installation documentation. |
| Platform support | Multiple Linux architectures including x86 and ARM variants | Current download page offers builds across many architectures. |
| SQLite search limitation | No full-text search with SQLite | Official AList search documentation recommends another database when full-text search is required. |
When to upgrade your hardware
Upgrade AList when the server becomes the file data path or local indexing/download tasks dominate.
Local proxy turns AList into a sustained transfer server
Large uploads cause temporary memory/cache pressure
Search indexing and offline-download workflows grow
AList issue history includes upload-related memory growth, and current release notes mention streaming upload slices to avoid buffering whole parts in memory.
Users uploading multi-gigabyte files through AList.Search databases and offline-download temporary files add local disk/database work that does not exist in a basic cloud-file listing deployment.
Large multi-storage libraries using search and download automation.Plan hardware growth with confidence
Scale AList by keeping direct traffic direct where possible and giving proxy/index/temp workloads appropriate resources.
Prefer direct provider links when privacy/policy allows
If the storage driver can send clients directly to the provider, the AList host avoids relaying every file byte.
This can keep a ZimaBoard 2 lightly loaded even when users download large files.Use local proxy only when you need it
Local proxy can solve provider/client compatibility and access-control needs, but it turns host network throughput into a hard part of the path.
Dual 2.5GbE is useful for high local proxy traffic; 10GbE only matters for genuinely faster local workloads.Keep temp/offline-download data off tiny system storage
AList's offline-download documentation requires a temporary folder for container workflows. Large jobs can consume local capacity independent of remote cloud capacity.
Map a dedicated SSD/HDD temp path when offline download is used heavily.Choose database features from search needs
SQLite simplifies a small deployment but lacks AList full-text search. Moving to another database adds memory, disk and backup requirements.
Upgrade for the combined AList + database/search stack, not just the file-list UI.Can it run on ZimaOS?
AList is currently available in the ZimaOS App Store under Productivity.
Install AList from the ZimaOS App Store
The current ZimaOS listing packages AList v3-class file listing/WebDAV functionality.
Open AList in the ZimaOS App StorePersist AList data separately from remote storage
The official Docker guide maps `/opt/alist/data`; cloud-drive files do not replace the need to preserve local application/database configuration.
Read AList Docker installationMeasure proxy and offline-download paths
AList can either redirect clients to providers or relay traffic locally. Test the exact driver and WebDAV/download strategy used on ZimaOS.
Read AList common driver proxy settingsChoose Zima hardware for AList
AList itself is lightweight; the right Zima tier depends on whether the server only lists remote storage or also proxies, downloads and stores large files.
Is AList mainly a cloud-storage control plane, or is the ZimaOS host carrying file data and local storage?
Mostly listing/direct links and modest WebDAV use
ZimaBoard 2 832 provides ample CPU/RAM and network capacity.
- Normal AList serverZimaBoard 2 832
- More proxy/search/Productivity servicesZimaBoard 2 1664
Heavy local proxy, offline download or multi-drive storage
Move to ZimaCube for integrated storage and stronger whole-server I/O headroom.
- Multi-drive AList storage serverZimaCube 2 Standard
- High-throughput proxy/storage and 10GbE workflowZimaCube 2 Pro
There is no official AList CPU/RAM minimum or fixed concurrent-transfer benchmark. Storage provider APIs, direct/proxy mode, WebDAV, file size, database/indexing and network path can change resource use significantly.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | A normal AList cloud-storage and WebDAV server. | Storage listing, direct links and moderate WebDAV/API use. |
|
Heavy local proxy or offline-download workloads can make network/temp storage more important than app CPU. | Get Now |
| ZimaBoard 2 1664 | AList plus more storage/search/Productivity services. | More concurrent transfer/control workloads and a larger application stack. |
|
16 GB is for broader server headroom; AList has no 16 GB requirement. | Get Now |
| ZimaCube 2 Standard | A multi-drive server where AList also fronts local storage. | Local file storage, proxy traffic, offline downloads and other storage apps. |
|
Choose it for integrated capacity/I/O, not because the AList UI is compute-heavy. | Get Now |
| ZimaCube 2 Pro | A high-throughput all-in-one file/storage platform. | Large local proxy transfers, multi-drive storage and 10GbE-capable workflows. |
|
10GbE only helps when clients, disks and upstream/provider paths can use it. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These FAQ topics follow query fan-out around AList's lightweight reputation, WebDAV, direct versus proxy traffic, large-upload memory, search databases and local temporary storage. Community/GitHub discussions are used for real pain points, not as minimum specifications.
How much RAM does AList need?
AList does not publish an official RAM minimum. Basic file listing and direct-link use can be very lightweight, while large proxied uploads/downloads, indexing and offline-download tasks can temporarily use substantially more resources.
Why can AList be lightweight but still use a lot of bandwidth or CPU?
Because AList has two very different roles. With provider direct links it mainly acts as a control plane; with local proxy or WebDAV proxy the server relays the actual file traffic.
Does AList WebDAV make the server handle all file data?
It depends on the storage and WebDAV strategy. Some operations can redirect or use provider links, while local/native proxy modes make the AList host part of the transfer path. Test the exact driver configuration.
Why can large AList uploads cause memory spikes?
Large multipart/provider uploads may involve buffers and caches. AList issue history contains memory-growth reports, and current releases include streaming upload-slice changes specifically intended to avoid buffering whole parts in memory.
Does AList need PostgreSQL or MySQL for search?
Not for normal AList operation. SQLite is sufficient for basic state, but the official search guide says full-text search is unavailable with SQLite, so another database is needed if that feature matters.
Where should AList offline downloads store temporary files?
Map a real local temporary folder with enough free space. Offline downloads can consume significant local capacity even when the final content is destined for remote/cloud storage.
Can ZimaBoard 2 832 run AList?
Yes. Its Intel N150, 8 GB RAM and dual 2.5GbE provide large headroom for a normal AList deployment. Heavy proxy traffic or local storage growth, not AList's baseline process, is more likely to justify an upgrade.
When should I choose ZimaCube 2 for AList?
Choose it when AList becomes part of a multi-drive local file server, offline-download system or high-throughput proxy/storage workflow. Cloud listing alone does not need ZimaCube-class hardware.
What sources and further reading informed this AList hardware guide?
AList's current official Docker, download, search, common-driver and offline-download documentation define persistence, architecture, proxy data paths, SQLite full-text limitations and local temp behavior. Current release notes and issue reports were used to understand large-upload memory behavior. Reddit self-hosted discussions reinforce AList's lightweight reputation and WebDAV use, but do not define hardware minimums.
