I think this is all your personal preference. All of these should work perfectly fine for regular nodejs projects.
OK thanks
I think
** Location - Helsinki
** Storage Type - Local (NVME SSD)
The doubt I have left is
** OS - Ubuntu / Fedora / Debian / CentOS
I would be oriented on Ubuntu or CentOS which should certainly include the possibility of installing NodeJS, but I do not know the strengths and weaknesses of the various OS
Iâm very much looking forward to that. I expect a lot of people will be very interested. Trying out docker locally is straightforward enough, but the prospect of using it on production sites still seems very alarming, to me at least - in particular such issues as managing databases (can I still use Navicat?) or managing files generally.
You donât manage the database through Docker, Tom.
Are the Wappler / Docker settings the same for Ocean and Hetzner?
Yes, there is no difference which cloud hosting provider you select.
You just hit deploy and docker image is uploaded.
1 Like
I know itâs no problem using Navicat when Docker is used locally. Can I do the same with hosting on DigitalOcean etc? (As you can tell, I know very little about all this but hope to learn more soon.)
This is also something which sounds alarming. I would never simply hit deploy usually. Is this necessary with Docker in a way it isnât when using conventional hosting/FTP etc? Or can I just upload individual files and folders etc? (These questions are probably very basic. I should probably wait until I have more experience before asking more questions.)
Itâs not working like that. You canât select a file and âhit uploadâ, thatâs not FTP and itâs not even similar to how FTP works.
And this is way better than working with FTP, nothing alarming to me actually âŚ
Iâm not sure what you mean about FTP (Iâm very familiar with how FTP works), but in simple terms, how would I make a simple change to a page locally and update that page on a site hosted using docker? Supposing there was a typo and a just wanted to change one word. Is there a quick, simple way?
Well, save your file and hit the deploy button âŚ
I suggest you to check the series of article by George about working with Docker to better understand how it works.
What i mean about FTP is that itâs an outdated technology. In the modern world the âuploadâ process of a website is not usually done through FTP.
There are packaging, versioning and deploy procedures involved nowadays.
So the deploy button only âdeploysâ a file? I think Iâve been assuming the âdeployâ button is equivalent to the âpublishâ button (another button Iâve never clicked).
I wonder if that applies to the way the majority of Wappler users work?
It rebuilds the image and deploys it to your target.
Well, this doesnât change the fact FTP is an outdated technology 
And thatâs just a habit left from using products like DW for 20(or more) years. Technology evolves, workflows you are just used to are not always the best.
Itâs hard to imagine that would always be a good option, but perhaps it will make sense when I try it.
I used FTP before Dreamweaver existed. (I very rarely use just FTP - ie the original, unencrypted version). But I see your point. However, I suspect there are advantages to both the old and new technologies.
Hi Tom
Yes, you can still use Navicat in exactly the same way as a ftp based setup or use the Wappler database manager. Docker updates the files and static images but leaves the database unchanged on deploys so your data is unchanged. For dynamic image/ document uploads etc you use static storage aka spaces on D.O and S3 component. Bit more work but the result is deployment from a fast edge cached CDN so well worth it I confess i was really uncomfortable with the whole idea of docker but having used it on a major site re-write i have grown to both like and trust it.
For about the 4th time (Wappler keeps changing major features!!) i am doing a new series of videos in which i will be using docker/ Node. I was going to wait until i had a lot ready but perhaps I will release the project/ environment/ docker part early as there appears a lot of members who are unclear about how it works (as i was until about a month ago)
You donât, you test on the local docker image of your site and when you are sure it is working correctly you deploy to production target. The entire process takes about 30 seconds - minute depending on how many static images are being uploaded but if you test locally first no error should sneak through.
Basically it makes a tarball of your site and explodes that tarball on the droplet
Hi Brian
Thanks - thatâs reassuring. I am particularly interested in your thoughts and suggestions. I know you have a great deal of experience in development and hosting generally. However, youâve indicated this is new territory for you too, and youâve expressed some apprehension about it - and a little frustration from time to time.
Yes, initially i was terrified about the possibility of overwriting/ losing data on deploy but to be honest my view has changed significantly over the last month and now I have got to grips with it I am very comfortable (still do data backups as .sql file anyway but that has always been my way.
It does change your workflow. With FTP and smaller non mission critical sites I sometimes authored directly into production, not a good way but so be it. I would then test, sometimes panic as I have broken something and the frantically fix it. Now I spend much more time on the local development target, run and test there thoroughly and probably only do a deploy every few hours and when confident everything is properly tested.
1 Like
Itâs encouraging that after only a month youâre already comfortable with docker etc. Losing data, and control generally, is what worries me too.
As far as deploying is concerned, can you control at all whatâs included in the deployment? I might want to upload one or two files from a local version of a site which includes unfinished sections, temporary copies and possibly various other files I donât want uploaded. I imagine this way of working wonât be possible.
I was thinking it might be an advantage to store images on S3 storage anyway. Some of my customers have 10s of thousand of images. However for the relatively few non-product images I was thinking of storing them locally (in the same location as the other files on the site). I suppose that would mean uploading them each time you make a change, which is not ideal. I expect Iâll have to change my ways - doubtless for the better in some respects.
Itâs an all or nothing choice, no single file uploads
1 Like