Did you configure your domain registration to point at namecheap nameserver(s)?

EDIT: also check on their "Domain" tab that the domain is active.

EDIT 2: the "nameservers" slot should be fine with "Namecheap BasicDNS".

EDIT 3: The A record entry should be for host "@" to indicate the basic domain name (realupnow.com), with other host names like "www" and "mail" for "www.realupnow.com" and "mail.realupnow.com".

Installing "daedalus preview" without network seems to clock in at 860M.

Note that the SSL credentials system is built upon "domain name control"; i.e., that you are the current renter of the proposed domain name, and in control of the DNS resolution for it.

The "http" validation done by Let's Encrypt via certbot involves them, at an external host, looking up the domain name (realupnow.com) so as to access a file via HTTP that certbot has prepared. This is only possible if you have control of the domain resolution to make that name resolve for that external host to your host and then also run an HTTP service for offering that file.

Firstly, the configuration does not include SSL setup so the service is http and not https.

Next, you will need to convince your browser that the FQDN (fully qualified domain name) realupnow.com resolves to the IP address 127.0.0.1 (or the other one if you prefer, since nginx listens on all interfaces, i.e. both lo and eth0).

Traditionally a browser would end up using the standard libc function gethostbyname to determine the IP adddress to use, and this is technically configured via /etc/nsswitch.conf and /etc/hosts. If all is per traditionally normal, then it is enough to add a line to /etc/hosts:

127.0.0.1 realupnow.com

(with a terminating newline). That would declare the DNS resolution for realupnow.com to be 127.0.0.1.

More recently browser developers have introduced new and interesting ways of resolving domain names, so it's possible that this won't work for you. In that case, you should install surf and trial this via the command line start:

$ surf http://realupnow.com/info.php

Unless of course, you rather enjoy some browser wrestling

Note that it's http without a trailing s.

Look at end of /var/log/nginx/error.log.

Directory /var/www/realupnow.com exists and is readable by www-data ?

php7.4-fpm is started?

btw, code things (like configuration files) are best displayed with code tagging rather than quote tagging since that will avoid word-wrap linebreaks that otherwise might cause confusion.

No.

Rather, please show the content (with ls -l) of /etc/ngiginx/sites-enabled/, and your nginx configuration file.

Does /etc/nginx/sites-enabled have more than the link to your config?

The alphabetically first of any pathnames there will be the virtual server configuration that handles access without proper server name ("127.0.0.1").

For testing, you may temporarily add a line to /etc/hosts to allow direct access via your external server name:

127.0.0.1 example.com

for trialling http://example.com/info.php (or even https://example.com/info.php once the SSL credentials have been set up)

Something for everyone: http://radio.garden

Perhaps you could give more than a trace of a hint of the choices for the whole installation process. That end state of booting up to a command line is fairly unusual. It suggest in particular that you opted to not install any desktop s/w but that's a bit inconsistent with being surprised by ineffectual startx.

A virtualbox VM is basically the same as a qemu VM insofar as Devuan installation is concerned. The range of h/w emulation choices might differ but that would only be an issue if you'd play fancy with that.

@fanderal, there may be some ram used by various tmpfs mounts, which use RAM but are not reported together with process RAM usage. You could check with:

df -h | grep -E 'Filesystem|tmpfs'

Note that all Devuan scripts are links to the ceres script. E.g.

/usr/share/debootstrap/scripts/daedalus -> ceres

You'll need to set that.

That's not how it works.

The s.c. round-robin is merely that the domain name has multiple resolutions that the authorative nameserver serves in different orders upon subsequent requests; apt just picks whichever it receives first.

Afaik there's no easy way to selectively exclude servers from the list.

You may however use /etc/hosts to override the name lookup with your favourite resolution. If, say, you prefer m10k.jp you would add their IP as resolution for deb.devuan.org:

160.16.137.156  deb.devuan.org

For anything more advanced I think you will need a local nameserver.