I’m not really sure how to ask this because my knowledge is pretty limited. Any basic answers or links will be much appreciated.

I have a number of self hosted services on my home PC. I’d like to be able to access them safely over the public Internet. There are a couple of reasons for this. There is an online calendar scheduling service I would like to have access to my caldav/carddav setup. I’d also like to set up Nextcloud, which seems more or less require https. I am using http connections secured through Tailscale at the moment.

I own a domain through an old Squarespace account that I would like to use. I currently have zero knowledge or understanding of how to route my self hosted services through the domain that I own, or even if that’s the correct way to set it up. Is there a guide that explains step by step for beginners how to access my home setup through the domain that I own? Should I move the domain from Squarespace to another provider that is better equipped for this type of setup?

Is this a bad idea for someone without much experience in networking in general?

  • themadcodger@kbin.earth
    71·
    3 days ago

    We all got to learn somewhere!

    Lot of good advice here, but sometimes people forget what it’s like to be a beginner. Since you don’t know what you’re doing, I would recommend not trying to host things on your home server and access it from the outside world. That usually involves port forwarding on your router, and that comes with a lot of risks, especially if you don’t know what you’re doing. Others have mentioned it, but a better option when you’re starting off is to rent a vps and host your software there.

    Squarespace might work, but my guess is it’ll be easier to transfer your domain elsewhere. You can follow guides for that online and it’s pretty straightforward.

    Having a vps, a domain name, you’re most of the way there. On your vps, you’ll want to install a reverse proxy, which is what routes incoming urls to the right place (nextcloud.domain.tld goes here, calendar.domain.tld goes there).

    Docker is another thing I’d recommend learning as a lot of what you’ll self host will likely be in a Docker container. I’d watch a few YouTube videos to see how it’s done. This channel has some great videos, and there are others out there.

    It seems like a lot, but learn a little here and there and don’t expect to have this all working overnight. You’ll get there!

      • mic_check_one_two@lemmy.dbzer0.comEnglish
        2·
        2 days ago

        I actually wanted to ask about that… Is it considered best practice to run a bunch of different compose files, and update them all separately? Or do you just throw all of them into a single compose file, and refresh the entire stack when updating?

        The latter definitely seems like it would be more streamlined in terms of updating, but could potentially run into issues as images change. It also feels like it would result in a bunch of excess pulls. Maybe only two images out of a dozen need to be updated, but you just pulled your entire stack. Maybe you want to stay on a specific version of one container, while updating all the others. Sure you could go edit the version number in the compose, but that means actually remembering to edit the compose before you update.

        • uranibaba@lemmy.worldEnglish
          1·
          20 hours ago

          Is it considered best practice to run a bunch of different compose files, and update them all separately?

          tl;dr I do one compose file per application/folder because I found that to suite me best.

          I knew about docker and what is was for a long time, but just recently started to use it (past year or so) so I’m no expert . Before docker, I had one VM for each application I wanted and if I messed something up (installed something and it broke or something), I just removed the entier VM and made a new one. This also comes with the problem that every VM needs to be stopped before the host can be shutdown, and startup took more work to ensure that it worked correctly.

          Here is a sample of my layout:

          .
├──audiobookshelf
│  ├──config
├──diun
│  └───data
├──jellyfin
├──kuma
├──mealie
│  ├──data
│  └──pgdata
├──n8n
│  ├──n8n_data
│  └──n8n_files
├──paperless
│  ├──consume
│  └──export
├──syncthing
│  └──data
└───tasksmd
    └──config

          I considered using one compose file and put everything in it by opted to instead use one file for each project. Using one compose file for everything would make it difficult to stop just one application. And by having it split into separate folders, I can just remove everything in it if I mess up and start a new container.

          As for updating, I made script that pulls everything:

          #!/bin/bash

function docker_update {
    cd $1
    docker compose down && docker compose pull && docker compose up -d
}
docker_update "/path/to/app1"
docker_update "/path/to/app2"
docker_update "/path/to/app3"

          Here is a small sample from my n8n compose file (not complete file):

          services:
  db:
    container_name: n8n-db
    image: postgres
    ...
    networks:
      - n8n-network

  adminer:
    container_name: n8n-db-adminer
    image: adminer
    restart: unless-stopped
    ports:
      - 8372:8080
    networks:
      - shared-network
      - n8n-network

  n8n:
    container_name: n8n
    networks:
      - n8n-network
      - shared-network
    depends_on:
      db:
        condition: service_healthy

volumes:
  db_data:

networks:
  n8n-network:
  shared-network:
    external: true

          shared-network is shared between Caddy and any containter I need to access to externally (reverse proxy) and then one network that is shared between the applications.