Imports, categorization, financial calculations and background tasks can increase PostgreSQL and worker memory together.
For larger transaction histories or more frequent background processing.Maybe Hardware Requirements: RAM, CPU, Storage & Personal Finance
Learn Maybe Finance hardware requirements for RAM, CPU, PostgreSQL, Redis, Sidekiq, Docker and ZimaOS hardware.
Maybe hardware requirements at a glance
Maybe is the archived predecessor to the actively maintained Sure fork. The original project remains self-hostable with Docker, but its GitHub repository was archived in July 2025 and is no longer actively maintained. Current ZimaOS still packages Maybe as a four-service Finance app.
- CPU
- Maybe upstream does not publish one universal CPU minimum. A 2025 AWS deployment guide recommends t3.medium or larger—2 vCPU—while current Pigsty and Senate guides focus on deployment architecture rather than defining an upstream core-count floor.
- RAM
- Maybe upstream does not publish one universal RAM minimum. The supplied AWS guide recommends 4 GB RAM for its EC2 deployment. Current ZimaOS reserves 1 GB each for web, worker, PostgreSQL and Redis—4 GB total reservations. These are practical deployment choices, not an upstream universal minimum.
- Application stack
- Maybe's current archived Docker stack uses a Rails web service, Sidekiq worker, PostgreSQL 16 and Redis. Pigsty likewise describes Maybe as a typical Rails application using PostgreSQL in production and Redis for background jobs.
- Storage
- The AWS tutorial uses 15 GiB gp3 storage as its practical host starting point. ZimaOS persists Rails storage, PostgreSQL and Redis separately. Long-term capacity should include financial history, uploads, database growth and backups.
- Maintenance status
- The upstream repository is archived and no longer actively maintained. This is a deployment/security consideration, not a hardware requirement; current users should understand that Sure is the active community continuation.
- Best Zima starting point
- ZimaBoard 2 832 with 8 GB RAM is a reasonable current host for the full Maybe stack and provides margin above the 4-GB AWS tutorial/ZimaOS reservation class. Choose larger hardware only when database growth, backups and other applications justify it.
From official requirements to the right setup
Maybe sizing starts with the archived project's four-service architecture, then adds deployment-maintenance risk, database growth, background jobs, backups and co-hosted applications.
-
Official requirements
Confirm that you intentionally want archived Maybe rather than its actively maintained Sure fork. Hardware can be sufficient while software lifecycle becomes the more important constraint.
-
Confirm your needs
Treat the application as Rails web + Sidekiq + PostgreSQL + Redis. Pigsty and the archived upstream Compose both reinforce this four-layer architecture.
-
Leave room to grow
Use 2 vCPU / 4 GB RAM / 15 GiB only as the supplied AWS author's practical EC2 tier, not as an official Maybe minimum. Current ZimaOS separately reserves 4 GB across the four services.
-
Run it on ZimaOS
Place database/app data on reliable SSD storage, test imports and background jobs, and monitor PostgreSQL, worker and Redis resource use. Upgrade based on the complete stack rather than the Rails web process alone.
Check every playback client
- Archived Maybe versus actively maintained Sure
- Rails web and Sidekiq worker load
- PostgreSQL database size and backups
- Redis background-job/cache activity
- Transaction/account import volume
- Persistent Rails/PostgreSQL/Redis storage
- Docker image/version pinning and update strategy
- Other ZimaOS apps sharing CPU, RAM and SSD
Official minimum requirements
Maybe upstream does not publish a universal production CPU/RAM/disk table. The repository is archived, and the best numeric sizing evidence in the supplied sources comes from a 2025 AWS tutorial rather than an official requirement.
Do not call 2 vCPU / 4 GB / 15 GiB the official Maybe minimum. It is one author's AWS recommendation. The current ZimaOS package independently reserves 4 GB across web, worker, PostgreSQL and Redis. For current deployments, software-maintenance status should be considered alongside hardware.
| Requirement | Official minimum | What this supports |
|---|---|---|
| Upstream status | Archived / no longer actively maintained | Repository archived July 27, 2025; Sure is the active community fork. |
| Upstream CPU minimum | No universal official minimum published | Current archived project docs describe Docker/self-hosting rather than a fixed processor floor. |
| Upstream RAM minimum | No universal official minimum published | No current official Maybe document defines one whole-system RAM floor. |
| AWS tutorial tier | 2 vCPU, 4 GB RAM, 15 GiB gp3 | Third-party July 2025 deployment recommendation, not an upstream minimum. |
| ZimaOS aggregate reservations | 4 GB total | Current manifest reserves 1 GB each for web, Sidekiq worker, PostgreSQL and Redis. |
| ZimaOS architectures | amd64 and arm64 | Current package remains available under Finance. |
When to upgrade your hardware
Maybe hardware growth is driven by PostgreSQL, worker jobs, data retention and co-hosted apps, while the archived software lifecycle remains a separate operational concern.
Database and Sidekiq jobs create memory pressure
Financial history and backups outgrow the current SSD
The host grows into a broader self-hosted stack
Persistent Rails storage and PostgreSQL data need separate backup retention. Long-running finance data can turn storage/backup planning into the main requirement.
For users retaining years of data and multiple backup generations.Other databases, media, automation and storage services can dominate CPU/RAM. Upgrade the physical server from total workload evidence.
For all-in-one ZimaOS systems.Plan hardware growth with confidence
Maybe scales most cleanly by separating application/database storage, backups and background-job resources.
Keep PostgreSQL and Rails data on SSD
The current ZimaOS package persists Rails storage and PostgreSQL separately. Use reliable SSD-backed storage for active data.
Add SATA/NVMe SSD rather than relying on onboard eMMC.Keep backups separate from the live application disk
Financial data is high-value. Reserve separate backup capacity and test restores instead of using all free SSD space for the active database.
Use additional HDD/SSD or NAS backup storage.Add RAM when PostgreSQL plus worker load needs it
Moving from 8 GB to 16 GB is appropriate when measured database/worker/co-hosted-app memory grows, not because Maybe itself defines a 16-GB tier.
Choose ZimaBoard 2 1664 based on real memory pressure.Consider migration to Sure before scaling archived software
If the main reason to invest further is long-term operation, the actively maintained Sure fork may be a more important decision than buying more hardware for archived Maybe.
Treat software lifecycle as a decision gate before hardware expansion.Can it run on ZimaOS?
Maybe remains available in the ZimaOS App Store under Finance even though the upstream repository is archived. The current package still uses the original maybe-finance image with PostgreSQL and Redis.
Install Maybe from the current ZimaOS App Store
The current package uses ghcr.io/maybe-finance/maybe:latest for web and worker, plus PostgreSQL 16 and Redis 8.2.1.
Open Maybe in the ZimaOS App StoreUnderstand the four 1-GB reservations
Current ZimaOS compose reserves 1024 MB each for the web service, Sidekiq worker, PostgreSQL and Redis. These reservations total 4 GB but are not a hard upstream requirement.
Review the ZimaOS Maybe manifestAccount for the archived upstream lifecycle
The Maybe repository is read-only and no longer actively maintained. If deploying new long-term infrastructure, compare migration to Sure instead of assuming the archived 'latest' image will keep receiving upstream fixes.
Read the Maybe final release/statusChoose Zima hardware for your Maybe workload
Maybe's four-service stack fits comfortably on ZimaBoard 2 832 for personal use, but the project's archived status should be evaluated before investing in larger dedicated hardware.
Are you maintaining an existing Maybe deployment, or building a larger long-term finance/home-server platform?
Existing personal Maybe deployment
ZimaBoard 2 832 provides 8 GB RAM and enough CPU for the four-service stack at personal scale, with margin above the 4-GB practical/package class. Add SSD for the database. Use 1664 only when the wider host needs more RAM.
- Existing personal Maybe deploymentZimaBoard 2 832
- More database/worker and co-hosted appsZimaBoard 2 1664
Larger long-term platform or major new hardware investment
Before moving to ZimaCube 2, evaluate whether migrating to the actively maintained Sure fork is the better software decision. If storage/NAS needs independently justify ZimaCube 2, Standard or Pro can host the finance stack.
- Storage-first archive/NAS with MaybeZimaCube 2 Standard
- Heavier multi-service finance/database stackZimaCube 2 Pro
- Only for unrelated GPU/AI workloadsZimaCube 2 Creator Pack
This is a workload guide, not an endorsement of archived software for new long-term deployments. Hardware sufficiency and software-maintenance/security lifecycle are separate questions.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Existing personal Maybe deployments and modest finance stacks. | Maybe web, Sidekiq, PostgreSQL, Redis and several lightweight ZimaOS apps. |
|
Use SSD for database/app storage and weigh the archived upstream status before investing further. | Get Now |
| ZimaBoard 2 1664 | Existing Maybe with larger database/worker load and more co-hosted apps. | Larger PostgreSQL data, more background jobs and additional self-hosted services. |
|
Do not claim Maybe requires 16 GB; consider whether migration to Sure is more valuable than hardware expansion. | Get Now |
| ZimaCube 2 Standard | Storage-first NAS hosting an existing Maybe deployment and large backup history. | Maybe plus household storage, backups and moderate services. |
|
Choose for storage needs, not because Maybe itself needs a larger CPU. | Get Now |
| ZimaCube 2 Pro | Heavier all-in-one database/NAS system that still hosts Maybe. | Maybe plus databases, backups, many containers and broader homelab services. |
|
For a new long-term deployment, software lifecycle may be a stronger reason to move to Sure than to scale Maybe hardware. | Get Now |
| ZimaCube 2 Creator Pack | Maybe on a server independently required for GPU/AI workloads. | Maybe plus separate local AI or creator applications. |
|
Extreme overkill for Maybe itself. | 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
Maybe's supplied sources range from current 2026 deployment docs to an archived upstream project and a 2025 AWS tutorial. The maintenance status and source scope matter as much as the numbers.
How much RAM does Maybe need?
Maybe upstream never established one universal current RAM minimum. A July 2025 AWS guide recommends 4 GB RAM, while the current ZimaOS package reserves 4 GB in aggregate across web, worker, PostgreSQL and Redis. Treat 4 GB as a practical deployment class, not an upstream minimum.
Is Maybe still actively maintained?
No. The maybe-finance/maybe repository was archived on July 27, 2025 and states that it is no longer actively maintained. Sure is the community-maintained continuation.
What does Pigsty say about Maybe hardware?
Pigsty's current Maybe guide focuses on architecture rather than a fixed CPU/RAM minimum. It correctly describes Maybe as a Rails application using PostgreSQL in production and Redis for background-job queues.
What does the AWS Medium guide recommend?
It recommends t3.medium or larger with 2 vCPU, 4 GB RAM and 15 GiB gp3 storage. That is a third-party AWS deployment recommendation for personal use, not an official Maybe minimum.
Is Senate's Maybe version current?
The supplied Senate page currently generates a deployment around Maybe version 0.4.3. Because the upstream project later reached its final archived state, Senate's pinned example is useful for deployment structure but should not be treated as the latest Maybe software baseline.
Why does ZimaOS reserve 1 GB for each service?
The current ZimaOS manifest assigns 1024 MB reservation to Maybe web, Sidekiq worker, PostgreSQL and Redis. These four reservations total 4 GB but are resource metadata, not a universal hardware minimum.
Does Maybe require a GPU?
No for the base finance stack. It can call remote OpenAI APIs when configured, which does not require a local GPU. Local AI inference would be a separate workload.
Can ZimaBoard 2 832 run Maybe?
Yes for personal use. Four N150 cores and 8 GB RAM provide reasonable headroom above the four-service package reservations. Put the database on SSD and consider the archived software lifecycle before making a large new hardware investment.
What sources and further reading informed this Maybe hardware guide?
Pigsty's current 2026 guide accurately describes Maybe's Rails/PostgreSQL/Redis architecture but does not publish a hardware minimum. The Maybe GitHub repository is the authoritative lifecycle source: it is archived, no longer actively maintained and remains self-hostable with Docker. Senate currently presents a version-0.4.3 Compose deployment, so it is treated as a deployment example rather than a current version authority. The supplied July 2025 Medium guide recommends t3.medium or larger with 2 vCPU, 4 GB RAM and 15 GiB gp3 for its AWS deployment; those figures are retained as a practical third-party tier. Current ZimaOS Maybe manifest data was additionally checked and shows four 1-GB memory reservations across web, worker, PostgreSQL and Redis.
