Deployment for a production environment is never without complications. And that is affected by how much you choose to configure yourself. I can't speak for Heroku, Digital Ocean, or Python Anywhere, because I haven't used them. Perhaps some of their users will comment.
Even with virtual hosting it is best to pick one of the kernels that they have customized to work well with their virtualization mechanisms. (If you had a physical host you would need to do kernel configuration yourself.) I know that AWS and Linode keep their eye on kernel security updates and will offer new versions promptly, but you will need to keep your eyes open and install the upgraded versions when they become available. They may or may not include application updates as part of these packages, particularly database, but also perhaps http server and python version, though if you want to pick your own version of these then you will be reinstalling them when the kernel upgrades happen. And you must watch for security updates of the packages that you choose to hand install, which will include Django. (One of the attractions of shared hosting is that the provider takes care of more of these things.) But as far as picking your own version goes, you really want to stay close to the latest stable version, rather than having to back port security patches yourself. You also don't want to go with versions so old that they are unsupported, or the people finding new exploits will be limited to the bad guys. Doing the work right along to stay close to current best practices is valuable so that you don't have a large panic update to do when your version becomes unsupported, needs a security fix, and some old, previously deprecated, way of doing something has been dropped. You will want to learn how to use one of the automated deployment tools, since setting things up by had every time gets old, and is error prone. As a python guy, I've had fun with fabric, but there are other fine open source and free tools. In addition to running pip for your, they can remotely run apt, rpm, etc., build your database, http server, python version (including plugging the http server into the desired python using modwsgi, for example). (Note that it is not difficult to have multiple versions of python installed on a Linux system without them getting in one another's way. So the kernel scripts can run with the version for which they have been designed and tested, and you can still have your favorite running behind your http server, running Django. I'm unaware of AWS pricing. Last I checked Linode can be as cheap as $5/mo (I pay closer to $20), depending on how big a server you need. Linode, and I presume AWS and others, provides a base amount of bandwidth to the outside world, and if your site has a lot of users (including DDOS attacks) you may have to pay for extra. Having them run backups for you is an extra cost option (at least for Linode, and probably for most others). Otherwise your bandwidth to storage at your house or office counts against your bandwidth allotment. (And you should back up this way, at least occasionally, even if your regular backups are handled by the provider.) Linode will host DNS records for your VPS. I presume the others will too, though there may be differences as to whether there is extra cost. If you're going to accept money, don't do it on your server: Hook up with PayPal and/or one of the other credit card service providers. You don't want sensitive customer financial (or medical) records on your site. (You would need full time security staff, and probably private physical servers to do that safely.) If you have a very high traffic site, then most providers, including Linode and certainly AWS, can offer geographic diversity of server location, which helps with responsiveness, and the ability to continue to conduct business if a natural disaster takes one of the provider's server farms off line for a while. (Most of us don't need this. And if you have backups not collocated with the failed farm, you can bring up an alternate instance quickly.) There is no substitute for doing your own research into costs, features, restrictions, and reputation of the various possible providers. Bill On Sat, Nov 30, 2019 at 1:54 PM Debabrata Chakraborty < debobroto.c...@gmail.com> wrote: > Thanks a million ke1g! > > That was really helpful. I am definitely going to use PostgreSQL now. > > Only one question remains. I'm willing to deploy my site in any reasonably > priced virtual server hosting. You mentioned using VPS means I can install > what I want. > > So does that mean - it doesn't matter *which version of Django (i.e. > Django 2.2.5) I use for the site development,* they will all be equally > supported inside a VPS hosting plan? > > Also, what is the least complicated, least technically challenging Django > hosting option for a beginner like me? > > Thanks again > > Deb > > > *On Saturday, November 30, 2019 at 8:01:15 PM UTC+5:30, ke1g wrote:* > > SQLite is fine for development, but, unless things have changed, it is >> single threaded, and unsuitable for a production environment. Most folks >> seem to go for MySQL, though the fork MariaDB is usually preferred no that >> Oracle owns MySQL. I prefer PostgreSQL (or just Postgres) because I think >> that it comes closest to the SQL standard and is competitive in other >> respects. Any of these have to be "administered" (though is many cases the >> provider helps with this), so if this is for a toy installation, SQLite may >> be OK. >> >> SQLite, however, is built into Python these days, and even in older >> Python versions it was just a pop install, so providers can't squawk about >> the version. But shared hosting (as opposed to virtual server) will mean >> that a particular python version is installed, and the SQLite version in >> that version of Python is what you are going to get. But SQLite handles >> queries written for older versions well, and you will wind up with a quite >> recent version, so you are unlikely to be using any features that are too >> new for the installed version. >> >> Virtual server hosting means that you can install what you want, but does >> mean that you will be administering the whole OS as well as the database, >> the http server, and even the version of Python, installing new versions >> when there are security updates, etc. >> >> I, personally, haven't used any of the providers that you mentioned. The >> last time I deployed on a shared host I used WebFaction, and was quite >> satisfied. Today I use Linode, who provide a virtual server, and are also >> quite satisfactory (though you must, last time I checked, use Linux, which >> I consider a plus). >> >> > > *On Sat, Nov 30, 2019 at 9:02 AM Debabrata Chakraborty > <debobr...@gmail.com> wrote:* > > Hi everyone, > > I'm a beginner Django developer. So my apologies in advance for newbie > like questions. > > I am building my site with *" *Django version 2.2.5 *"* and *" *SQLite > 3.30 *" *in back-end. My question is - > > *#* Do services like "Heroku", "Digital Ocean", "Python Anywhere" and > "AWS" - have limitation on *which version of Django* or *which DBMS* I > can use? > > I've seen this before with PHP/MySQL hosting where some hosting companies > will limit *which version *of PHP or MySQL one can use. Is the same > applicable to Django hosting in the above mentioned hosting platforms as > well? > > I will very much grateful if you can help me out with this confusion. > > Best > > Deb > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/e0918e60-bdf4-4721-a931-1e030d697558%40googlegroups.com > <https://groups.google.com/d/msgid/django-users/e0918e60-bdf4-4721-a931-1e030d697558%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB%2BAj0ujQ6hnDdj-8_kLnxVw-W5WZ-C9v_Mnz68EWn8GQCeiYA%40mail.gmail.com.
