Self-hosted file infrastructure in Rust for small teams that need storage control, reliable large-file uploads, WebDAV/WOPI, and operations visibility without adopting a full private-cloud suite.
Route files across local, S3-compatible, and remote-node backends with one dual-licensed Rust + React service built for deployment, auditability, and modification.
AsterDrive is a self-hosted file service, dual-licensed under MIT or Apache 2.0, for people who want control over where files live and how they move through the system. It is built around the core drive workflow: upload reliably, organize folders, recover mistakes, share access, connect WebDAV clients, open Office files through WOPI-compatible services, and route objects to the right storage backend.
It is not trying to become a full private-cloud suite. AsterDrive focuses on file infrastructure: storage policies, large-file upload paths, team and personal workspaces, sharing, version history, WebDAV, WOPI, auditability, and deployment/operations tooling.
The current v0.4.x line is the active development line. In the 0.x series, minor versions carry major compatibility or product-scope changes, while patch versions carry smaller feature and maintenance updates.
AsterDrive is a good fit when you want:
- a single self-hosted service with embedded frontend assets
- SQLite out of the box, with optional PostgreSQL / MySQL later
- local filesystem, S3-compatible object storage, Azure Blob Storage, Tencent COS, OneDrive / SharePoint, SFTP, or remote AsterDrive follower-node storage
- upload strategies for both small files and large objects: direct, resumable chunked, object-storage presigned, and object-storage multipart
- personal and team workspaces with quotas, shares, trash, tasks, audit logs, and storage policy groups
- WebDAV access with independent accounts and scoped root folders
- Office preview/editing through external WOPI services such as OnlyOffice or Collabora
- a codebase that is meant to be read, modified, and deployed without a plugin marketplace or enterprise stack
AsterDrive is probably not the right first choice when you need:
- a complete collaboration suite with calendars, contacts, chat, mail, and an app ecosystem
- mature native desktop and mobile sync clients today
- an ultra-minimal web UI over a single server directory
- managed database/Redis/object-storage high availability, cross-region strong consistency, automatic cross-region traffic failover, or enterprise compliance guarantees
- a vendor-managed SaaS where someone else owns the deployment and data responsibility
- File safety first - trash, version history, locks, quota checks, and cleanup tasks are part of the core workflow, not decorative extras.
- Storage control - policies can route uploads to local storage, S3-compatible storage, Azure Blob, Tencent COS, OneDrive, SFTP, or remote follower nodes by user, team, and file size.
- Large-file paths - the backend negotiates direct uploads, chunked uploads, object-storage presigned uploads, and object-storage multipart uploads based on policy and object size.
- Interoperability without sprawl - WebDAV and WOPI cover practical client and Office workflows without turning the project into an all-in-one cloud suite.
- Operations built in - health checks, runtime configuration, audit logs, background tasks, storage tests,
doctor, and migration commands are first-class features. - Hackable core - Rust backend, React frontend, SeaORM migrations, explicit error codes, API docs, and clear service/repository boundaries.
For a local HTTP trial, prepare a writable data directory and start the official image:
mkdir -p ./data
sudo chown -R 10001:10001 ./data
docker run -d \
--name asterdrive \
-p 127.0.0.1:3000:3000 \
-e ASTER__SERVER__HOST=0.0.0.0 \
-e "ASTER__DATABASE__URL=sqlite:///data/asterdrive.db?mode=rwc" \
-v "$(pwd)/data:/data" \
ghcr.io/astercommunity/asterdrive:latestOpen:
http://127.0.0.1:3000
Complete the first-start setup screen to create the initial admin. Ordinary registration is
available only after setup and never grants the administrator role.
Fresh installations allow the first login over HTTP by default. When the first administrator is created through an HTTPS origin, AsterDrive automatically enables Secure cookies before the following login. For production, keep AsterDrive behind HTTPS and confirm HTTPS-only cookies are enabled in System Settings.
You can also use the included Compose file:
mkdir -p ./data
sudo chown -R 10001:10001 ./data
docker compose up -dSee the Docker deployment guide for the full setup.
git clone https://github.com/AsterCommunity/AsterDrive.git
cd AsterDrive
cd frontend-panel
bun install
bun run build
cd ..
cargo runOn first startup, AsterDrive will automatically:
- generate
data/config.tomlunder the current working directory if it does not exist - create the default SQLite database when using the default database URL
- run all database migrations
- initialize the shared three-stage setup state; after creating the administrator, configure a default storage policy suitable for the deployment
- initialize built-in runtime configuration items in
system_config
- Do not expose
:3000directly to the public Internet. Put AsterDrive behind a reverse proxy that handles HTTPS, upload limits, WebDAV/WOPI passthrough, and security headers. - Configure public site URLs before relying on share links, WebDAV URLs, mail links, or WOPI callbacks.
- Run
./aster_drive doctorafter deployment and upgrades. The default SQLite search acceleration expectsFTS5 + trigram tokenizersupport. - Plan backups for the database, uploaded blobs, config, and any external object-storage credentials. Start with Backup and restore.
- If you enable WOPI, test real
docx,xlsx, andpptxfiles through the final public URL and confirm that edits save back into AsterDrive.
- folders, breadcrumbs, list/grid views, search, multi-select, and batch operations
- file upload, folder upload, download, rename, move, copy, delete, restore, and purge
- archive download, online archive compression/extraction, and background task progress
- thumbnails, browser-native previews, read-only ZIP/7z archive manifest previews, and configurable external preview apps
- Monaco-based text editing, lock awareness, version history, restore, and version deletion
- personal workspace plus team workspaces
- independent files, shares, trash, tasks, quotas, audit records, and policy groups per workspace
- public file and folder shares at
/s/:token - optional share password, expiration time, download limits, open/download counters, and direct links
- shared-folder browsing with child-file download, preview, and thumbnail access
- HttpOnly cookie auth plus Bearer JWT for API clients
- first-user setup, registration controls, activation, password reset, and email-change confirmation
- WebDAV accounts with independent passwords, scoped root folders, database-backed locks, custom properties, and a small DeltaV subset
- WOPI launch sessions and file endpoints for Office preview/editing through external WOPI hosts
- optional Passkey / WebAuthn registration and login endpoints
- local storage, S3-compatible storage, Azure Blob Storage, Tencent COS, OneDrive / SharePoint, SFTP, and remote follower-node storage policies
- policy groups that route uploads by user, team, and file size
- optional local-only blob deduplication using SHA-256 and reference counting
- object-storage upload/download strategies:
relay_stream,presigned, and multipart uploads - remote-node upload/download strategies:
relay_streamandpresigned - streaming upload/download paths where the selected strategy allows it
- admin overview, users, teams, storage policies, policy groups, remote nodes, shares, tasks, locks, runtime settings, and audit logs
- schema-driven runtime configuration stored in
system_config - health endpoints:
/health,/health/ready, optional/health/memory, and optional/health/metrics - storage policy and remote-node connection tests
- background task records for archive jobs, thumbnail generation, mail dispatch, cleanup, and runtime tasks
- periodic cleanup for uploads, trash, locks, audit logs, teams, WOPI sessions, and orphaned blobs
- Swagger UI in debug builds with the
openapifeature, plus static OpenAPI export
The user and deployment documentation is published with Astro Starlight at drive.astercosm.com.
- Getting started
- User guide
- Workspaces and teams
- Sharing and public access
- Preview processing and WOPI
- Storage backends
- Remote follower storage
- Docker deployment
- Production checklist
- Backup and restore
- Operations CLI
- Developer docs
- Architecture
- API overview
- Report vulnerabilities privately through GitHub Security Advisories or
report@esaps.net— see SECURITY.md for the full policy - Published advisories: github.com/AsterCommunity/AsterDrive/security/advisories
security.txt(RFC 9116): drive.astercosm.com/.well-known/security.txt
- Rust
1.95.0+ - cargo-nextest
- Bun
- Node.js
24+for the current Docker frontend build stage
# Backend
cargo run
cargo check
cargo nextest run
cargo nextest run --features openapi --test generate_openapi
# Frontend
cd frontend-panel
bun install
bun run dev
bun run build
bun run check- Type checking uses the TypeScript 7 native
tsccompiler - Linting uses
biome, not ESLint - TypeScript
enumis not allowed; useas constobjects - Type-only imports must use
import type
src/ Rust application, services, API, and runtime
crates/aster_drive_metrics/ Product metrics contracts and AsterForge adapters
crates/aster_drive_migration/ SeaORM migrations
crates/aster_drive_model/ Shared product models and SeaORM entities
crates/aster_drive_storage/ Storage contracts, descriptors, and structured errors
frontend-panel/ React admin/file panel
docs/ Deployment and end-user documentation
developer-docs/ API, architecture, testing, and internal positioning docs
tests/ Integration tests
Licensed under either of:
- Apache License, Version 2.0 (LICENSE-APACHE)
- MIT license (LICENSE-MIT)
at your option. Copyright (c) 2026 AsterCommunity & AptS-1547.
