What is required and why

• Virtual server, so that publishing application could be installed.
• Domain name, so that others could know where to go.
• Secure connection, so that data communication between a user and the publishing application would be secured.
• CDN service, so that operation of the publishing applcation would be quicker and more stable.

How much it costs

Virtual server. A good and plentiful minimum resources costs around 8 euros per month. Hourly billing is used. Many variations in resources and network topology. Hosted by Hetzner, with a data center in e.g. Finland.

Domain name. This is to be purchased from Hetzner as part of its web hosting package, which includes one free web address (assuming a rather common extension such as .net, .com or .org is selected) for a monthly fee of 2 euros at minimum. This package includes an initial fee of around 10 euros.

Secure connection. Hetzner's web hosting package also includes a free secure connection in the form of a Symantec Basic SSL Certificate.

CDN service. A separate user account is registered with the Bunny CDN for this purpose. An advance payment of a few euros may be sufficient to last for a long time. When it is fully used, the publishing application will continue to operate, but with a higher risk of server(s) getting overloaded.

How to pay the easiest

For both Hetzner and Bunny CDN services, the easiest way to pay is by prepayments, which in the case of Hetzner increases the "credit balance" that is automatically used to pay the invoices.

The customer does not need to provide their bank details to the developer/seller of the publishing application. Instead the prepayments are made by sending a prepayment using PayPal's internal money transfering, after which the full amount of the prepayment is manually transferred to Hetzner and Bunny CDN.

The PayPal money transfer is preferred, especially in the initial phase, but in the later phases the Hetzner prepayment can also be paid by bank transfer. When making the transfer, the Hetzner user account's id code is entered in the reference data so that the amount sent is directed to the correct user account. It may not be necessary to pay the Bunny CDN prepayment at all for a long period of time, or even regularly if it is not used much. Bunny CDN also has other services available for use, for which a customer can choose to pay from the same prepayments.

If requested separately, the customer can receive a copy of a monthly invoice, but this is a manual operation, so sending a copy of each invoice might not happen.

Pricing pages

• Hetzner (pilvipalvelut): https://www.hetzner.com/cloud/
• Hetzner (webhosting): https://www.hetzner.com/webhosting/
• Bunny CDN: https://bunny.net/pricing/

Contract lenghts

Hetzner charges for the use of virtual servers, even if they are shut down. If they are completely removed, leaving only the user account for use, billing will stop immediately after the current hour.

For Hetzner's web hosting service, customer may have to pay another monthly fee for the next month, depending on when the service is suspended. For more information on this take a look at the Hetzner's documentation: 30 days to the end of the month

Domain names are typically those that are renewed or not renewed annually. Hetzner's web hosting service package includes a free domain name, with the annual fee paid from its initial and monthly fees. The domain name purchased from Hetzner is the property of the customer. If the customer terminates the web hosting package, he may continue to own the domain name by paying an annual fee to Hetzner or transfer it to another domain name registrar.

Using of the Bunny CDN can be terminated at any time, but of course it is not advisable to terminate it while all other essentials are still in use.

Billing cycles

Hetzner invoices its services on a monthly basis, which would mean two separate invoices (for the virtual server(s) and the web hosting package). The monthly billing dates would remain the same, but would vary on a client-by-client basis. The first payment reminder for the first invoices will be sent 5 days after receipt of the invoice, for subsequent invoices after 10 days.

When prepayments aren't made

In Hetzner's case, the advance payment is intended to cover the costs for the next 30 days. If it starts to appear that the prepayment may not be paid, the customer will be contacted and it is anticipated that all Hetzner services used by the customer might have to be deactivated. This may mean that the virtual server with all its data may be deleted and after that it cannot be restored.

Paypack of prepayments

At least in the case of Hetzner, prepayments can be refunded for the remaining amount (minus the balance of the last invoice). According to the information received from Hetzner's customer service, the refund will be made using the payment method originally used to make the payments, i.e. PayPal payments via the publishing application developer to the PayPal account and bank transfers directly to the bank account of the publishing application customer. It is not quite clear whether there is a service fee for a bank transfer when paying back prepayments, but in the SEPA (Single Euro Payments Area) it should not be very much.

What does "overage costs" mean

Overage costs means additional fees over allotted usage limits. In the case of Hetzner's virtual server, it means that virtual server's outbound data traffic is free up to 20 terabytes (1000 gigabytes) and after that customer will get charged based on overage pricing, which in Hetzner's case is 1 eur per terabyte. The means of limiting data traffic to ensure that it remains within the free 20 terabytes will be agreed with the customer. There is a risk that some fraudulent parties might use up the free data traffic through bots.

Minimal resources for the publishing application

Resources such as disk space, memory/performance for server equipment are available on request. As minimum resources, 8 GB memory and 4 vCPUs (processor time slots) have been considered as suitable, which at 15.7.2024 pricing means a maximum cost of 8,04 eur per month. Then, a virtual server will be in use, i.e. the processor is used by multiple Hetzner's client. Dedicated servers, i.e. servers used by only a single customer, are more expensive. A publishing application can be distributed over several servers, as explained in the writing about network topology changeability.

Alternative service providers

There are no separate agreements with Hetzner or Bunny CDN to remain their user. They just simply are excellent in terms of pricing, functionality, features and willingness to evolve. The similar permanence of maintainability is also an important criterion for using them. A domain name and SSL certificate can be obtained elsewhere.

Management of login credientials

The control of the Hetzner and Bunny CDN user accounts remains solely with the developer/seller. The reasons for this include the need to authenticate with an identity document to obtain them and the risk of making incorrect configurations. Various optionalities that those accounts offer can be utilitized at the customer's request without any extra charge, provided that they are not too burdensome to implement. E.g. email accounts and subdomains included in Hetzner's webhosting service package and Bunny Storage, which another service of Bunny, could be useful.

More business-like operations still ahead

The publishing application is not yet sold as a business, but as a private person, so at this stage the customer does not pay extra for product development, maintenance, etc.

To get a feel for how to increase credit balance, two different ways of transferring money to Hetzner was tried: directly from bank account (Nordea) and using the Wise service. Both were paid on Thursday and on Monday, immediately after the weekend, the credit balance had increased using both. The service charge for Wise matched exactly the amount that was left to transfer to Hetzner. The bank did not charge a service fee. The fact that both the sender and the recipient were located in the SEPA (Single Euro Payments Area) certainly helped to speed up the transaction flow. Hetzner is a German company, where its headquarters are located.

Bank transfer using Wise

Wise's interface is not so complicated that it would need a lot of explanation. You can get off to a good start by clicking the "Send money" button. Since it seemed relevant to be able to assess the consequences of having something wrong with the transfer details, the name of the recipient (Hetzner) was set to the name of the bank and the reference number was not only set to the required Hetzner customer ID, but it also contained text string "Customer ID:", but just as quickly the payment was made available as with a bank transfer.

The payment intermediary Wise charged a service fee of 0.41 eur for a transfer of 10 eur, which is probably an acceptable amount. The amount that ends up in Hetzner's account is clearly shown and you can see from your own online bank that ten euros have been deducted from the account. The money transfer in this case has also gone through Trustly, which has the advantage that the identity is verified by a bank ID and no other proof of identity is required.

Bank transfer using own bank (e.g. Nordea)

In addition to the Hetzner IBAN, it is important to include the Hetzner customer number in the reference data. A slight mistake made in the other try out allowed to deduce that the customer ID in the reference number could also contain a little extra like "Customer ID:" before the actual customer number and the amount of money would still end up where it was supposed to. However, it is probably recommended to use only the customer number as reference number. Nordea Bank did not charge a service fee (it was probably included in the personal service package).

An online bank transfer could not be much easier. Just as easy as transferring money domestically. A slightly different amount was sent for the sake of differentiation, i.e. 3 euros, which ended up in full in Hetzner's account.

Other services and about proving identity

PayPal's Xoom service may be as good as Wise. Other payment services that have emerged as potentially viable include Azimo, Instarem, Revolut, MoneyGram and transferGo. There are some country restrictions on the location of the sender for payment intermediaries such as Western Union, SendMoney24, GlobalWebPay and Ria. Skrill could be a good one, but at the time of writing, individuals cannot use it to send payments to businesses.

Some of these services don't let you do much until you've proved your identity in somewhat cumbersome way, possibly requiring to take a selfie, and prove your address by scanning an invoice that came in the mail, for example. In the case of the Wise service that was tried, you can use Trustly as a payment method, so you don't need to prove your identity beyond your bank ID. According to the Wise website, Trustly is available in Estonia, Finland, Spain, Poland, Sweden and Denmark.

The customer may well be interested in testing the number of users the publishing application can handle, and such load testing is acceptable as long as it does not go on for hours. Even a minute of automated loading of some writing of a work, e.g. with a load testing application available online, is sufficient to get a good feel for it. In a single-server system, it should be possible to load one article with basic resources, e.g. 8000 times per minute with a response time of 70 ms. Considering that e.g. most blog posts on the internet get only a few hundred reads per month, the basic resources should be "just fine" for many purposes. Images of public works will always be loaded via the CDN service, if a prepayment for the CDN service has been made.

Lazy loading method is used for images and videos, i.e. only the parts of a webpage already on the screen and those within 1000 pixels of it have their images etc. loaded. The resolution of the images to be loaded has also been optimised to avoid unnecessarily loading images with too high resolution, both when the page is first loaded and when the browser window is resized. On large pages, resizing the browser window could easily result in up to thousands of image download attempts if the browser window were resized continuously for, say, a minute, so to take into account such a possibility only the image layout is adjusted according to the browser window size and the need to load different images having different resolution is programmatically considered coly momentarily.

One quick way for the customer to reduce the load on the publishing application is to increase the cache time per work, which is 5 seconds by default. This caching means that e.g. one writing of a work is not generated separately for each page load, but the last one is stored on the server in a file which is used for e.g. the next 5 seconds or as long as it is configured to be. It can be up to two hours. The generating of a writing and other parts of a work causes always a moderate load on the server's processor, and there is always the possibility that there will be a lot of page load requests at once. Reading the generated part of the work from a file causes, by comparison, a very low load on server resources.

Load balancing of server hardware and software would not be fully utilized if the Linux server that first receives the incoming signals is configured to be highly restrictive in the outbound bandwidth. That would be done with the Linux's tc command (from "traffic control"), and the reason for its use could be e.g supposed threat that bots would be deliberately programmed to consume a monthly traffic by downloading moderate amounts of different content such as images and pages of works many times over a long period of time. One would probably prefer not to pay several hundred euros extra instead of the expected e.g. ten euros. It might be least stressful to be prepared to pay three times more than expected by keeping the bandwidth only slightly limited and hopefully finding out again and again that nothing bad happened.

Normally, many data centre service providers would charge for outbound data from servers of the publishing application after data transfer volumes exceed e.g. 20 TB, as in the case of Hetzner. This amount, i.e. 20 000 GB, is a large amount for a low traffic instance of the publishing application. To be on the safe side, an additional limitation is applied to the servers of the publishing application on a per-customer basis to prevent the monthly data transfer volumes from exceeding that 20 TB by limiting the transfer rate of the virtual network card of the server to 60 mbps or 7.5 MB/s (see calculation: https://www.wolframalpha.com/input/?i=60Mbps+in+TB%2Fmonth). The portion of the cost that exceeds the specified data transfer limit is referred to as 'overage costs' and the data that goes out of the server is referred to as either 'egress data' or 'outbound data'. If the data centre services are provided by a provider other than Hetzner or if 20 TB is otherwise not the limit for the overage costs, this will be explicitly mentioned before the conclusion of the service agreement.

If the number of visitors suddenly increase, it could make it difficult to log in with a username or do any kind of editing, for example, because the load would make everything very slow. The images in the writing "Changing the network topology of the publishing application" give few ideas about how to change network topology to make it all more resistant to high external load. Other quality of service improvements include simply adding more vCPUs for virtual servers to use or switching to dedicated servers. For a bit more information on these, see the writing "Becoming a customer of the publishing application".

(This is only relevant for customers who want something more specific in addition to the features of Symantec Basic SSL Certificate that is installed for free. This is also an example of how simple tasks can become more complicated.)

When using a publishing application in a browser, the web address will start with either HTTPS or HTTP. First one of these mean that the connection from the user's browser to the servers used by the publishing application is secure, i.e. the traffic could not, according to general consensus, be intercepted and captured, e.g. on public WiFi networks. At least by monitoring the network, that is. The security of user devices is a separate issue. To protect the connection, an SSL certificate is needed, also known as Secure Sockets Layer (SSL) and Transport Layer Security (TLS).

Pricing: SSL certificates are priced on an annual basis, and it is not necessarily necessary to buy anything more feature-rich than PositiveSSL, which is available from many places (e.g. Namecheap) and with some luck for half the price from the same company from which you can buy a domain name. PositiveSSL costs less than 10 eur per year and is always purchased for a specific domain or subdomain and cannot be changed later. If you pay for five years at a time, the price would be around 5 eur per year. Once purchased, the certificate cannot be transferred from one vendor to another.

Notice: With a standard HTTP connection, all those connected to the same local area network may very well be able to capture the network traffic generated by others on that local area network using appropriate software (e.g. Wireshark), provided that no fancy security or encryption is in place. Or it could be that large organisation's such as an educational institution's network is used to log on to the publishing application or to read published works, in which case the ease with which users connected to that network can monitor each other's activity on that network depends largely on the competence of the IT department of that organisation. From outside the organisation, eavesdropping would be more difficult if it were not a wireless network, but on the other hand, when the browser and server parts of a publishing application communicate with each other, it is not really sufficient for the communication to be encrypted that the initial path, i.e. where the device used for browsing is physically located, is protected by an organisation, since there may be long physical and virtual distances from there to the server used by publishing application. In between, there are many different routing points and different parts of the network where data would travel unencrypted.

Deployment: SSL certificate deployment consists of a series of tasks that result in the final SSL certificate as a plaintext file to be copied to the server. The customer of the publishing application can perform all of the following steps, provided that the customer focuses on each of the steps with sufficient care. If the provider of the publishing application performs all the steps to deploy the SSL certificate, money would again have to be transferred as a PayPal payment and, finally, the customer might want to end up as the owner of the purchased SSL certificate, which requires a transfer of rights from one party to another. The purchase of an SSL certificate and all the steps involved are only necessary if the customer uses a different web address for the publishing application than one meant for testing purposes (defined on the first phases of becoming a customer).

1. registration to a marketplace (may be the same as when buying a domain name such as Namecheap)
2. purchase of an SSL certificate (the cheapest one, PositiveSSL, is sufficient)
3. starting the SSL certificate signing process by generating a CSR code (https://decoder.link/csr_generator)
4. copying the private key that gets generated at the same time (see image 1)
5. copying the CSR (Certificate Signing Request) code into the text field
6. select the Domain Control Validation (DCV) method (email validation must be chosen)
7. wait for a message to be received by email (see image 2)
8. click on the link in the validation message and enter the validation code when prompted (included in the same email)
9. wait for the second message to be received by email (see image 3)
10. extract the contents of the attached zip package from the email containing the SSL certificate to a directory (includes .crt and .ca-bundle files)
11. join the contents of the extracted files with the private key (create a new freely-named file with a .pem extension, containing first the contents of the .crt file, second the contents of the .ca-bundle file and third the private key)
12. send the .pem file to the publishing application provider

After step 9, you can send the emailed zip file to the publication application provider and skip the rest of the steps, but that alone is not enough, as the generated private key is still needed. The private key can be included directly in the email as text, as it is base64 encoded and cannot be distorted while the email travels over the internet.

For more information on the CSR code, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/337/67...

For more information on the DCV validation method, see for example: https://www.namecheap.com/support/knowledgebase/article.aspx/9637/6... (olennaisia ainoastaan alaotsikoiden "Receive an email" ja "Changing DCV methods" alla olevat tekstit ja kuvat)