Is it safe to just delete the folder with binary for this process and all other stuff?
Yes. No. Maybe.
It really depends on how the vendor intended an application to be deployed and what an admin did when installing it.
Some applications (and all their dependencies) are indeed deployed in their own sub directory, which can be a single flat directory or a large sub directory tree, often mimicking the conventional Linux root file system, e.g. with an etc sub-directory containing configuration files, [s]bin for binaries, a var sub-directory containing data etc. etc.
If you didn't deploy any other applications in that same subdirectory ; deleting that will completely remove the application.
Possibly you adjusted the application config. Fairly typical adjustments to make are changing the persistent data and logging directories to elsewhere on your system.
How can I identify, where it's configured to be started on startup?
Fairly typical to see are services/daemon processes started by systemd as in the example below. In that case systemctl status should list the unit files and all processes started by those and systemctl -a and other switches can be useful too.
A tool like pstree can be quite useful to visualise parent child relations and see which process started what. When only systemd is used that will give very much similar output as systemctl status but when other mechanisms are used, this will usually give you an insight.
Then there are some more "obscure" methods, for example some people like to use the @reboot cron timestamp specification to have cron (re)start services after a reboot.
pstree -a
systemd --switched-root --system --deserialize 22
├─/usr/bin/spamd
│ ├─spamd child
│ └─spamd child
├─agetty --noclear tty1 linux
├─atd -f
├─auditd
│ └─{auditd}
├─chronyd
├─crond -n
├─dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
│ └─{dbus-daemon}
├─dhclient -1 -q -lf /var/lib/dhclient/dhclient--eth0.lease -pf /var/run/dhclient-eth0.pid -H server eth0
├─dovecot
│ ├─anvil
│ ├─auth
│ ├─config
│ ├─imap
│ ├─imap-login
│ └─log
├─fail2ban-server -s /usr/bin/fail2ban-server -xf start
│ └─8*[{fail2ban-server}]
├─firewalld -Es /usr/sbin/firewalld --nofork --nopid
│ └─{firewalld}
├─httpd -DFOREGROUND
│ ├─httpd -DFOREGROUND
│ ├─httpd -DFOREGROUND
│ ├─rotatelogs -l /var/log/httpd/error_log.%Y.%m 86400
│ ├─rotatelogs -l /var/log/httpd/access_log.%Y.%m 86400
├─master -w
│ ├─anvil -l -t unix -u
│ ├─pickup -l -t unix -u
│ ├─proxymap -t unix -u
│ ├─qmgr -l -t unix -u
│ ├─smtpd -n smtp -t inet -u -o stress= -s 2
│ └─tlsmgr -l -t unix -u
├─mms
│ └─85*[{mms}]
The "master" process in that pstree list is a good example. That odd process name is actually postfix being started from the postfix.service systemd unit. That would be more easily found in the systemctl status output:
└─system.slice
├─postfix.service
│ ├─ 1110 /usr/libexec/postfix/master -w
│ ├─ 1112 qmgr -l -t unix -u
│ ├─ 1121 tlsmgr -l -t unix -u
│ └─11508 pickup -l -t unix -u
├─spamass-milter.service
│ └─1032 /usr/sbin/spamass-milter -g postfix -p /run/spamass-milter/postfix/sock
What else I should know/do to safety delete it?
Identify how a service is started and then stopping it is usually a good first approach.
Then get in the habit of not installing things from source, but use package managers or for example snap or run a container.
