Cloud Deployment

Two things to notice about how that is quoted. The prices are in the provider's own currency, because that is what the page says and what the card is charged; the rupee figure carries the date and the rate, because both move. And DigitalOcean's page adds that from 1 January 2026 it bills per second, with a minimum charge of sixty seconds, which matters to a student: a server built for a demonstration and destroyed the same evening costs pennies.

What a student can get free

The GitHub Student Developer Pack is worth applying for with a college email address, and its own page listed these on 30 September 2026:

• Microsoft Azure: "Free access to 25+ Microsoft Azure cloud services plus $100 in Azure credit. For students aged 18+", with "no credit card required".
• Heroku: "Enjoy a credit of $13 USD per month for 24 months."
• Namecheap: "1 year domain name registration on the .me TLD" and "1 SSL certificate free for 1 year."

A hundred dollars of credit is more than a year of the server above. Check the pack yourself: the offers change, and this book's list is a snapshot with a date on it. The Namecheap domain is the piece students most often miss, and a name is what makes HTTPS possible at all.

What changes in the project

Almost nothing, which is the point of having kept every setting out of the code (Chapter 28):

COOKIE_SECURE=true is the one that matters for the security design: the sign-in cookie is then never sent over plain HTTP, and the application also sends the header that tells browsers to use HTTPS for the site in future (Chapters 31 and 46). It is one line in .env, and its test already exists (S12, Chapter 53).

The deployment diagram, redrawn

Chapter 25 drew where the system runs during the trial. The cloud version is the same diagram with three changes: the lab desktop becomes a virtual machine in a data centre, the phones reach it over the internet by name on port 443, and the Wi-Fi limit disappears.

Figure 58.1 Where the system would run on a rented server

@startuml deployment-cloud
!pragma layout smetana
node "Student's phone" <<device>> as Phone {
  artifact "canteen.apk" as Apk
}
node "Counter device" <<device>> as Counter
node "Rented server\n(1 GiB, Ubuntu 24.04)" <<device>> as Server {
  node "Ubuntu 24.04" <<executionEnvironment>> as Os {
    node "Nginx" <<executionEnvironment>> as Nginx
    node "Node.js 24" <<executionEnvironment>> as Node {
      artifact "canteen-preorder" as App
    }
    node "MySQL 8.0" <<executionEnvironment>> as Db {
      artifact "canteen\ndatabase" as Data
    }
  }
}
Phone --> Nginx : HTTPS 443, from anywhere\n(Wi-Fi or mobile data)
Counter --> Nginx : HTTPS 443
Nginx --> App : HTTP\n127.0.0.1:3000
App --> Data : TCP\n127.0.0.1:3306
@enduml

The environments and the artifacts inside are identical: Nginx, Node.js with the application, MySQL with the database. That is the reward for keeping the application and the database off the network (Chapter 25): moving to the cloud changes the outermost box and nothing within it.

What a student must do that the college did for them

On the college's machine, the IT in-charge owned the machine, its network and its patches. On a rented server, the team owns all three, and three things follow:

1. The machine is on the public internet from the minute it exists. Within hours, automated programs will be trying to sign in to it. Chapter 60's firewall and SSH keys are not optional there.
2. Someone must apply security updates, or the machine becomes a liability to everyone.
3. The bill continues after the project ends. Destroy the server when the examination is over, and keep the code, which is the thing that matters.

Do this for your project

1. Decide honestly whether you need the cloud. If a local machine meets your constraints, say so and cost the alternative anyway.
2. Prefer a small virtual machine for this paper: it is what teaches server configuration, and it is cheaper.
3. Apply for the GitHub Student Developer Pack with your college email, and read the offers on the day you need them.
4. Quote prices from the provider's own page, with the date; convert with one dated rate if your report is in rupees.
5. Change settings, not code: the same application should run in both places.
6. Turn on COOKIE_SECURE and HTTPS the moment you have a name.
7. Destroy the server when you no longer need it, and write the date in your report.

Mistakes that cost marks

"We will deploy to the cloud" with no provider, no size and no price.

A price with no date, in a report read six months later.

A rupee figure with no rate, which cannot be checked or updated.

Claiming an offer the provider does not make, such as a student credit from a company that is not in the pack.

Code that must be edited to deploy, because settings live in it.

A server left running for months after the project, on a card nobody watches.

Quick revision

• The cloud buys a public address, a name and therefore HTTPS; it costs a monthly bill and administration.
• Virtual machine (you install everything) against a platform service (the provider does): for this paper, the machine, because server configuration is on the syllabus.
• Published prices, 30 Sep 2026: $4, $6, $12 a month for 512 MiB, 1 GiB, 2 GiB; per-second billing since 1 Jan 2026.
• Student pack on the same date: Azure $100 credit, Heroku $13 a month for 24 months, Namecheap a .me domain and one SSL certificate.
• Moving changes settings, not code: COOKIE_SECURE=true, Nginx on 443, a certificate.
• On a public server you own the firewall, the updates and the bill.

Questions you must be able to answer

1. What does a cloud deployment give a project like this that local hosting cannot? A public address and a domain name, so the system can be used from anywhere rather than only on the college network, and with them a certificate from a public authority, which is what makes HTTPS possible.

2. What is the difference between renting a virtual machine and using a platform service? With a virtual machine you get an empty Linux machine and install and maintain everything on it; with a platform service the provider runs the runtime and often the database, and you deploy only the application. The first teaches, and is examined by this paper's server-configuration topic; the second is quicker and usually costs more.

3. What would the worked system cost in the cloud, and how should that be quoted? About $6 a month for a 1 GiB machine at the prices published on 30 September 2026, with a domain name extra and the certificate free. It should be quoted in the provider's own currency with the date read, and converted to rupees only with a stated rate and date, because both prices and rates move.

4. What changes in the application when it moves to a rented server? Nothing in the code. The settings change: the cookie is marked Secure because the site is served over HTTPS, the database password is different, and Nginx serves port 443 with a certificate instead of port 80.

5. Why is COOKIE_SECURE false on the college's machine and true in the cloud? Because it tells the browser to send the sign-in cookie only over HTTPS. On the trial there is no HTTPS, so setting it would stop the cookie being sent at all; in the cloud there is, and it closes the trial's largest security weakness.

6. What responsibilities does a team take on with a public server that the college carried for them? Keeping it locked down from the moment it exists, since it will be probed within hours; applying security updates; and paying for it until it is destroyed, which should be done when the project no longer needs it.