DigitalOcean

Coming from a non-web development environment background, I was a bit lost a first and bewildered by all the varying tools and platforms, and spent much too long evaluating before eventualy deciding on Laravel as the main core of my development.

But as I started development with Laravel that lead me into discovering Vue.js for creating beautiful front-end components that were easy to configure and extend, so I decided to standardise on Vue.js for most of my front-end development.

During my search for additional Vue.js components, a chance comment in a @laravel forum , led me to discover Quasar Framework initially for it's wide range of in-built components ... but once, I realised that Quasar Framework allowed me to use the same codebase to create apps for SPA, PWA, iOS, Android, and Electron then I was hooked.

So, I'm now using mainly just Quasar Framework for all the front-end, with Laravel providing a backend API service to the Front-end apps.

I'm deploying this all to DigitalOcean droplets via service called Moss.sh which deploys my private GitHub repositories directly to DigitalOcean in realtime.

I use DigitalOcean because of the simplicity of using their basic offerings, such as droplets. In AppAttack, we need low-level control of our infrastructure so we can rapidly deploy a custom training web application on-demand for each training session, and building a Kubernetes cluster on top of DigitalOcean droplets allowed us to do exactly that.

#CloudHosting

We use DigitalOcean for our small to medium-sized projects. The nice thing about it is that the initial setup is so easy and fast that we can do in real time with our clients. This solidifies the bond with the clients because for maybe the first and only time they understand and see what's happening. We think DigitalOcean has set a new standard for cloud platforms in terms of price, design and workflow.

Knowing I'd have to move fast as a startup, choosing easy to use tools was imperative.

One of the first stack decisions any startup makes is which server host to use.

For HostedMetrics, I chose DigitalOcean because it gets the job done with minimal fuss and frustration. It has just the right amount of choices, tweaking, and details to get a startup up and running.

So, why not @AWS? As a software engineer, my experience with AWS stretches for over a decade. During that time, I've never held a positive opinion of the user experience on their platform. Newly added products suffer the same problem too, surprisingly.

Hosting updown.io started with a single OVH server and quickly grew to more server, first it was DigitalOcean VMs and we were very satisfied about them. But we then noticed some shortcomings about #IPv6 networking, although DigitalOcean supports it they don't provide the standard IP range to each VM (by choice) and thus have to block port 25 to avoid other machines being blocked in case of spammer. This is not good for us it means we can't monitor IPv6 SMTP servers properly, that's why we switched to @Vultr (one of their main competitors) which provides similar prices, more locations, and true IPv6 support with no blocked ports. Of course they offer less tools and the support is probably better at DigitalOcean but so far we're happy with @Vultr.

We still use some @OVH servers (which offers tremendous price/performance ratio) for the main web and database server + 2 of the daemons. In addition to this, we also have 2 DigitalOcean VMs for the secondary web and database server and for the automatic TLS termination proxy used to automatically issue Let's Encrypt certs for status page custom domains (for these servers the IPv6 port block is not an issue)

We use DigitalOcean mainly to provide remote development environments for Zulip contributors in situations where developing locally using our Vagrant setup isn't practical. There's a range of reasons:

• Situations where one needs a public IP address and SSL certificate (e.g. Facebook's OAuth system require that even for testing)
• Giving a contributor a development environment when their computer doesn't have the few GB of free RAM needed to run one locally
• Developer sprints, where our snapshot-based system can provision a working development environment for a potential new contributor in under a minute. This use case is particularly great because a machine that one only needs for 3 days is essentially free with Digital Ocean's pricing.
• A backup development environment when someone's laptop is being repaired.

One could do all of this with many hosting providers, but we've found it particularly convenient to use Digital Ocean for these applications.