Should be fine, but its definitely on the low end in terms of ram.
Nextcloud requires 128mb minimum, but ideally 512mb minimum.
Wordpress should fit in the left over space.
If your traffic/usage is not excessive, you should be fine.
this post was submitted on 01 Nov 2023
44 points (94.0% liked)
Selfhosted
39080 readers
391 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
This lines up with my experience. I have nextcloud and wordpress on two different vps's and just checked their ram usage.
- nextcloud: 468 MB
- wordpress: 120 MB
Caveat to the above is that nextcloud is installed bare metal rather than docker and I have both nextcloud and wordpress set up to use object storage as the media back end.
edit: To add to this OP, the reason we are only talking about ram numbers is that the cpu usage for these applications (with primarily only a single user) is pretty much zero most of the time, so you aren't going to be limited by the single core machine.
Also, depending on your use case (large amount of data on nextcloud or large media files in wordpress), you might run out of disk space pretty quickly. In those cases, you should consider using object storage as your nextcloud or wordpress media backends as it is cheaper than block storage (there are plugins/tutorials to configure object storage and Linode offers it).
WordPress tends to use a lot of RAM.
If you really need to use WordPress, take a VPS from ovh which gives you 4x the RAM at half the price
and doesn't work a third of the time.
I never had any problems for almost 10 years outside of a few major outages (that every provider has from time to time).
OVH has unexpected outages even on the higher plans, let alone the cheap ones. Google it.
You're better off either paying a little more and going with a more reliable provider or using Oracle VPS at least it's free.
I've been on OVH for 10 years now and had almost no downtime apart from the fire.
The fire? 😃 Keep these replies coming guys, they're amazing! 👍
You can get 2 Ampere ARM cores, 4G RAM and 40G space for that money at hetzner.
If you do a barebones install / without the Docker overhead it might work.
Docker overhead is practically zero. It's a bit more memory usage, but that's it.
Ahahaha
Convincing argument, but unfortunately a cursory Google search will reveal he was right. There is very little CPU overhead. The only real consideration is a bite extra storage and RAM to store and load the redundant dependencies of the container.
You're also ignoring the amount of work the kernel has to do to shift UUIDs around, the resources that the docker daemon itself uses and amounts of redundant stuff to make sure those processes are running that would usually be handled by systemd on a clean system. Yes, containerization is much better nowadays but still overhead.
Can't comment much about the docker side since it's not something I'm familiar with.
For the kernel part, assuming what you're referring to as UUIDs is the pid namespace mechanism, I'm failing to see how that would add overhead with containers. The namespace lookups/permission checks are performed regardless of whether the process is in a container or not. There is no fast path for non-containerized processes. The worst overhead that this could add is probably one extra ptr chase in the namespace linked list.