What those servers don’t have is anywhere to put anything. They serve a placeholder page, and nothing they do persists.<\/p>\n\n\n\n
So in this part we’ll add the state. We will set up a managed PostgreSQL with a connection pool, Valkey for caching and sessions, S3-compatible object storage for uploads, an encrypted shared filesystem both servers can mount, and a second network connected through peering.<\/p>\n\n\n\n
Then we’ll wire every connection detail into the servers through cloud-init.<\/p>\n\n\n\n
Let’s pick up where we left off.<\/p>\n\n\n\n
Prerequisites<\/h2>\n\n\n\n\n- Everything from part 1, still deployed. If you ran `tofu destroy`, run `tofu apply` to bring it back before continuing.<\/li>\n\n\n\n
- `UPCLOUD_USERNAME` and `UPCLOUD_PASSWORD` exported in your current shell. Environment variables don’t survive a new terminal, so if you’ve closed yours since part 1, set them again.<\/li>\n<\/ul>\n\n\n\n
Databases<\/h2>\n\n\n\n
The database module creates managed PostgreSQL with a connection pool and Valkey.<\/p>\n\n\n\n
To set this up, create a modules\/database\/variables.tf file:<\/p>\n\n\n\n![\"OpenTofu](\"https:\/\/upcloud.com\/media\/opentofu-database-module-variables-786x1024.png\")
<\/figure>\n\n\n\nThen add a modules\/database\/main.tf file:<\/p>\n\n\n\n![\"OpenTofu](\"https:\/\/upcloud.com\/media\/opentofu-managed-postgresql-resource-1024x834.png\")
<\/figure>\n\n\n\nFind the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\nFinally, add a modules\/database\/outputs.tf file:<\/p>\n\n\n\n![\"OpenTofu](\"https:\/\/upcloud.com\/media\/opentofu-postgresql-valkey-module-outputs-977x1024.png\")
<\/figure>\n\n\n\nAdd the password variable to the root variables.tf, with no default so OpenTofu refuses to run without it:<\/p>\n\n\n\n
variable “db_password” {
type = string
sensitive = true
}<\/p>\n\n\n\n
Set it through the environment rather than a .tfvars file that could end up committed:<\/p>\n\n\n\n
export TF_VAR_db_password=’something-long-and-random’<\/p>\n\n\n\n
Then in the root main.tf file, call the database module and add outputs for the hostnames, ports, and pool:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image14-712x1024.png\")
<\/figure>\n\n\n\nPorts and hostnames<\/h3>\n\n\n\n
Managed databases on UpCloud get an assigned port, not 5432 or 6379. Mine came back as 11569 and 11570. Anything that assumes the default port will fail, which is why the ports are outputs rather than constants.<\/p>\n\n\n\n
The hosts are hostnames rather than IPs. They resolve to private addresses, and those addresses can change during maintenance or failover while the hostname stays the same. Always hand the hostname to your application.<\/p>\n\n\n\n
Notice the two passwords are handled differently. You supply PostgreSQL’s, and Valkey generates its own, so the module has to read it back out. Marking it sensitive keeps it out of terminal output, but it still sits in plain text in the state file. More on that in the security section.<\/p>\n\n\n\n
Valkey also only accepts TLS connections. Configure your app with rediss:\/\/ or its TLS option, or it’ll fail to connect even with the right host, port, and password.<\/p>\n\n\n\n
Connection pooling<\/h3>\n\n\n\n
On UpCloud, PgBouncer isn’t a server you run. Connection pooling is built into managed PostgreSQL, and the provider exposes it as a resource, so the pool lives in the same module as the database.<\/p>\n\n\n\n
database and username reference the other resources instead of repeating their names as strings. That’s what makes OpenTofu create the pool after the database and user exist. With plain strings, it could try to build all three at once and fail. Setting username also restricts the pool to that one user.<\/p>\n\n\n\n
The default mode is transaction, the usual choice for web apps with short requests. A server connection is only held for the length of a transaction, so a small pool serves many clients. The trade-off is that anything relying on session state, like session-level prepared statements or advisory locks, won’t work reliably. Check your application before using it. session mode is the safe fallback.<\/p>\n\n\n\n
The pool’s URI points to the same host as PostgreSQL, but a different port, and its database name is the pool’s name rather than the real database. Build your connection string from db_host and db_name, and you’ll connect directly, bypassing the pool without any error. Use the URI.<\/p>\n\n\n\n
Run tofu apply.<\/p>\n\n\n\n
Both services build in parallel, since neither depends on the other, and each takes five to ten minutes, and there’s no progress output during that time. Don’t interrupt it!<\/p>\n\n\n\n
When it finishes:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image24-1024x690.png\")
<\/figure>\n\n\n\nOpenTofu lists pool_uri but hides its value. Read it with tofu output -raw pool_uri, and you’ll see the pool’s port and name in place of the direct ones.<\/p>\n\n\n\n
In the control panel, open Databases. Both services should show as running with the private network attached. Then go back to your network’s Routing tab. You’ll find a new route to 100.125.24.0\/22 with the source “Network peering.” You didn’t create it, but UpCloud wires managed databases into your private network using the same peering mechanism we’ll use ourselves later.<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image10-1024x523.png\")
<\/figure>\n\n\n\nUpCloud control panel showing the managed PostgreSQL and Valkey services running<\/em><\/p>\n\n\n\nObject storage<\/h2>\n\n\n\n
The storage module creates an S3-compatible object storage service, a bucket, and a user with scoped access.<\/p>\n\n\n\n
To set this up, create a modules\/storage\/variables.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image20-1024x530.png\")
<\/figure>\n\n\n\nThen add a modules\/storage\/main.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image19-1024x716.png\")
<\/figure>\n\n\n\nFind the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\nFinally, add a modules\/storage\/outputs.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image5-1024x783.png\")
<\/figure>\n\n\n\nThen in the root main.tf file, call the module and add outputs:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image13-1024x592.png\")
<\/figure>\n\n\n\nRegions<\/h3>\n\n\n\n
Object storage takes a region, not a zone, and they aren’t interchangeable.<\/p>\n\n\n\n
A region like europe-1 spans many zones, and its private network attachment only works if your network’s zone is one of them. To see the options, read the upcloud_managed_object_storage_regions data source.<\/p>\n\n\n\n
Each region lists its zones and a primary_zone, which is where the data physically lives. I picked europe-1 because its primary zone is fi-hel2, next to everything else in Helsinki.<\/p>\n\n\n\n
Access policies<\/h3>\n\n\n\n
A user with an access key can’t touch anything until a policy is attached. The policy is a standard S3-style IAM document, and the provider wants it URL-encoded, so jsonencode builds it, and urlencode wraps it.<\/p>\n\n\n\n
The policy is scoped to one bucket rather than the whole service. Within that bucket, it allows s3:*, because applications that use multipart uploads break in hard-to-trace ways when the action list is too narrow. The description is immutable after creation, so changing it later replaces the policy.<\/p>\n\n\n\n
If the arn:aws:s3 prefix looks odd, S3 is a protocol here, not a vendor. Any S3 client works against UpCloud once you point it at the endpoint, which is also why the access key IDs look like AWS ones.<\/p>\n\n\n\n
Private endpoint<\/h3>\n\n\n\n
The service exposes its endpoints as a set of objects, each with a type of private or public. The for expression in the output picks the private one. You’ll know it’s right because the hostname contains -private.<\/p>\n\n\n\n
Run tofu apply. The service takes around ten minutes, with the bucket, user, key, and policies taking a second each once they exist.<\/p>\n\n\n\n
When it finishes:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image24-1-1024x690.png\")
<\/figure>\n\n\n\nIn the control panel, open Object Storage. You’ll see the service with the nextcloud-data bucket, and the nextcloud user with the nextcloud-bucket-access policy attached.<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image12-1024x393.png\")
<\/figure>\n\n\n\nUpCloud control panel showing the object storage service<\/em><\/p>\n\n\n\nFile storage<\/h2>\n\n\n\n
The file storage module creates an encrypted NFS share that every app server can mount.<\/p>\n\n\n\n
First, add one output to modules\/network\/outputs.tf, so the share’s access list can use the network’s range instead of repeating it as a string:<\/p>\n\n\n\n
output “cidr” {
value = var.cidr
}<\/p>\n\n\n\n
Then create a modules\/filestorage\/variables.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image2-2-1024x617.png\")
<\/figure>\n\n\n\nThen add a modules\/filestorage\/main.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image17-1024x783.png\")
<\/figure>\n\n\n\nFind the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\nFinally, add a modules\/filestorage\/outputs.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image9-1024x429.png\")
<\/figure>\n\n\n\nThen, in the root main.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image22-1024x617.png\")
<\/figure>\n\n\n\nEncryption<\/h3>\n\n\n\n
encrypt = true can only be set when the storage is created. Add it later, and OpenTofu has to rebuild the whole service, so decide up front.<\/p>\n\n\n\n
Access list<\/h3>\n\n\n\n
The share exists as soon as it’s created, but nothing can mount it without an ACL entry. The target here is the whole private network range rather than individual server IPs, so the ACL doesn’t need touching when you scale the servers. The trade-off is that anything on the subnet can mount it, which in this build is only the app servers.<\/p>\n\n\n\n
Also notice the network block has no type field, unlike every other service in this build. File storage only attaches to private networks, and only one at a time.<\/p>\n\n\n\n
Mounting<\/h3>\n\n\n\n
File storage takes an address on your private network, just like a server, and which address it gets depends on what was created first. When I rebuilt everything from scratch, file storage came up before the servers and took 10.0.10.2, which pushed the servers to .5 and .6.<\/p>\n\n\n\n
That’s one more reason nothing here hardcodes an IP. The mount target comes from the nfs_host output, and the servers mount <nfs_host>:\/nextcloud, which we’ll add to cloud-init when we wire everything together.<\/p>\n\n\n\n
Run tofu apply, and when it finishes, you’ll see 3 added, plus the new outputs:<\/p>\n\n\n\n
file_share = “nextcloud”
nfs_host = “10.0.10.2”<\/p>\n\n\n\n
Your address will differ.<\/p>\n\n\n\n
In the control panel, open File Storage. You’ll see the service with the nextcloud share and one ACL entry for 10.0.10.0\/24 with read-write access.<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image21-1024x297.png\")
<\/figure>\n\n\n\nUpCloud control panel showing the file storage service<\/em><\/p>\n\n\n\nPeering<\/h2>\n\n\n\n
The peering module creates a second private network and connects it to the first. Nothing in this build needs it to run.<\/p>\n\n\n\n
It stands in for a management network, the kind of place you’d put monitoring or admin tools, and shows how to connect two networks without exposing either to the internet.<\/p>\n\n\n\n
To set this up, create a modules\/peering\/variables.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image7-1024x641.png\")
<\/figure>\n\n\n\nThen add a modules\/peering\/main.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image8.png\")
<\/figure>\n\n\n\nFind the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\nFinally, add a modules\/peering\/outputs.tf file:<\/p>\n\n\n\n
output “mgmt_network_id” {
value = upcloud_network.mgmt.id
}<\/p>\n\n\n\n
Then in the root main.tf file:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image23-1024x494.png\")
<\/figure>\n\n\n\nBidirectional connection<\/h3>\n\n\n\n
A peering on UpCloud only becomes active when it exists from both sides. That’s why there are two resources with the networks swapped. The mechanism is designed for connecting networks across different accounts, where each side has to agree independently. When both networks are yours, it feels redundant, but create only one, and you get a peering that shows as created and carries no traffic.<\/p>\n\n\n\n
The ranges can’t overlap, which is why the management network uses 10.0.20.0\/24 against the app network’s 10.0.10.0\/24, and why the CIDR has been a variable since the network module.<\/p>\n\n\n\n
If you ever remove a peering by hand in the control panel, it has to be disabled before it can be deleted.<\/p>\n\n\n\n
Run tofu apply, and when it finishes, you’ll see 4 added and the new mgmt_network_id output.<\/p>\n\n\n\n
In the control panel, open your app network’s Routing tab. You’ll see a route to 10.0.20.0\/24 with the source “Network peering” and the name nextcloud-app-to-mgmt.<\/p>\n\n\n\n
Under the DHCP routes, the same route appears as auto-populated, with 10.0.10.1 as the next hop, which is how servers on the app network learn to reach the management network.<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image1-1024x759.png\")
<\/figure>\n\n\n\nUpCloud control panel showing the app network’s routing table with a peering route to the management network<\/em><\/p>\n\n\n\nWiring it together<\/h2>\n\n\n\n
Every service now exists, but the app servers don’t know about any of them. This section passes the connection details into the servers through cloud-init, and mounts the shared file storage.<\/p>\n\n\n\n
Add these to modules\/compute\/variables.tf<\/a>:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image15-1024x830.png\")
<\/figure>\n\n\n\nFind the complete variables.tf file on GitHub here<\/a>.<\/p>\n\n\n\nThen replace the user_data in modules\/compute\/main.tf<\/a>:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image6-1024x764.png\")
<\/figure>\n\n\n\nThen pass everything in from the root main.tf. The compute module block becomes:<\/p>\n\n\n\n![\"-\"](\"https:\/\/upcloud.com\/media\/image11-1024x617.png\")
<\/figure>\n\n\n\nThe dependency graph<\/h3>\n\n\n\n
The compute module now references outputs from three other modules, so OpenTofu builds the database, storage, and file storage before the servers. There’s no depends_on anywhere in this project. The references are enough.<\/p>\n\n\n\n
Through the pool<\/h3>\n\n\n\n
The database connection is a single DATABASE_URL built from the pool URI, not a host and port. That’s deliberate. As the database section showed, connecting with the direct host bypasses the pool without any error, so the servers never receive the direct details at all.<\/p>\n\n\n\n
Two kinds of ${}<\/h3>\n\n\n\n
Inside the heredoc, ${var.nfs_host} is HCL. OpenTofu replaces it before the script ever reaches the server. $(hostname) is shell and runs on the server at boot. If you need a literal ${…} in a script, for a shell variable with braces, escape it as $${…}, or OpenTofu will try to interpolate it and fail.<\/p>\n\n\n\n
The mount<\/h3>\n\n\n\n
The share goes into \/etc\/fstab rather than a one-off mount command, so it survives a reboot. _netdev tells the system to wait for the network before mounting, which matters on a server whose only network is the private one. The mount runs after the package loop, because nfs-common has to be installed first.<\/p>\n\n\n\n
Replacing servers<\/h3>\n\n\n\n
user_data only runs at first boot, so changing it replaces the servers. Both get replaced in the same apply, which means a short outage while the new ones boot and pass their health checks. For a real deployment, look at create_before_destroy or roll the servers one at a time.<\/p>\n\n\n\n
Run tofu plan first. You should see both servers replaced and the load balancer’s backend members updated to the new IPs, and nothing else. Then apply, and give it about five minutes before you curl the load balancer.<\/p>\n\n\n\n
To confirm the wiring, open the console for either server and run:<\/p>\n\n\n\n
cat \/etc\/app.env
df -h \/mnt\/shared<\/p>\n\n\n\n
The first should show real values on every line, not ${var…}. The second should show the NFS share from your nfs_host mounted at \/mnt\/shared.<\/p>\n\n\n\n
Managing the infrastructure<\/h2>\n\n\n\n
Building this was half the job because there were some things that caught me while I was running this.<\/p>\n\n\n\n
Drift<\/h3>\n\n\n\n
The moment you change something in the control panel, the next plan shows it as drift, with OpenTofu proposing to put it back. That’s usually what you want.<\/p>\n\n\n\n
When the platform changes something on purpose, like the gateway adding its route to the router, ignore_changes tells OpenTofu to leave it alone. And if a resource exists but isn’t in state, tofu import adopts it instead of recreating it.<\/p>\n\n\n\n
State<\/h3>\n\n\n\n
By default, the state is a local file, and it holds every secret in this build in plain text. That’s fine while you’re learning. However, for anything shared, move it to a remote backend, which also stops two people from applying at once.<\/p>\n\n\n\n
Modules and environments<\/h3>\n\n\n\n
The repo’s root is a module that calls the seven submodules, and examples\/basic calls the root. That’s also how you’d separate environments: one root configuration each for staging and production, each calling the same module with its own name_prefix, CIDR, and plans, and each with its own state. Pin the module with ?ref=v1.0.0, so an update to the module never changes your production infrastructure by surprise.<\/p>\n\n\n\n
Security<\/h2>\n\n\n\n
Most of the security in this build isn’t about my configuration but about structure.<\/p>\n\n\n\n
Firewall rules<\/h3>\n\n\n\n
The app servers have no firewall rules, and that’s deliberate. UpCloud’s firewall filters public and utility<\/a> interfaces, and these servers have neither.<\/p>\n\n\n\nRules on them would filter nothing. The only way in is the load balancer, which forwards to the backends you named on the port you configured.<\/p>\n\n\n\n
Early in the build, my first server had a public IP, and I wrote firewall rules for it. Once the load balancer took over and the public interface came off, the rules had nothing left to guard.<\/p>\n\n\n\n
Removing the exposure is a stronger guarantee than a rule, because a rule can be misconfigured and a missing interface can’t.<\/p>\n\n\n\n
Every managed service follows the same pattern. The databases have public_access = false, object storage only exposes its private endpoint, and the file share’s access list only allows the private network’s range.<\/p>\n\n\n\n
Where the secrets end up<\/h3>\n\n\n\n
Marking a variable or output sensitive only keeps it out of the terminal and plan output. In this build, the database password, the Valkey password, the pool URI, and the object storage keys all end up in three other places:<\/p>\n\n\n\n
\n- The state file, in plain text.<\/li>\n\n\n\n
- The server’s metadata service, because they’re part of user_data. Any process on the server can read them.<\/li>\n\n\n\n
- \/etc\/app.env on each server, readable only by root.<\/li>\n<\/ul>\n\n\n\n
NOTE<\/strong>: Don’t pass long-lived credentials through `user_data` in production. Use a secret-management system, or workload identity where the platform offers it, and have the application fetch credentials at runtime. The gain is rotation: the app can fetch a new credential each time without rebuilding the server, while one baked into `user_data` is replaced only when the server is.<\/p>\n\n\n\nFor the state file, keep it in a remote backend, never in git, and encrypt it. OpenTofu can encrypt state natively from version 1.7, which is one of the features Terraform doesn’t have.<\/p>\n\n\n\n
Access<\/h3>\n\n\n\n
There’s no SSH into the servers, only the web console with the emailed root password. For regular access, the usual answer is a bastion host with a public IP and tight firewall rules, on the same private network.<\/p>\n\n\n\n
Or skip access entirely: put everything in cloud-init and rebuild instead of logging in. That’s closer to the point of infrastructure as code anyway. A fix made by hand over SSH is a fix your code doesn’t know about.<\/p>\n\n\n\n
And use an API sub-account for OpenTofu, not your main login. It can be restricted, and it can be revoked without locking you out.<\/p>\n\n\n\n
Wrapping up<\/h2>\n\n\n\n
Across both parts, we started with nothing and ended with a load balancer in front of two private app servers, managed PostgreSQL with connection pooling, Valkey, object storage, an encrypted shared filesystem, and a peered management network.<\/p>\n\n\n\n
The GitHub repository<\/a> packages this build as a reusable module. The root of the repo is the module itself, and examples\/basic shows how to call it, which is the fastest way to stand up your own copy.<\/p>\n\n\n\nEverything here runs on a standard UpCloud<\/a> account, and the provider covers far more than we touched. If you’re still on Terraform, OpenTofu<\/a> is worth the switch, if only for native state encryption.<\/p>\n\n\n\n
Databases<\/h2>\n\n\n\n
The database module creates managed PostgreSQL with a connection pool and Valkey.<\/p>\n\n\n\n
To set this up, create a modules\/database\/variables.tf file:<\/p>\n\n\n\n Then add a modules\/database\/main.tf file:<\/p>\n\n\n\n Find the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\n Finally, add a modules\/database\/outputs.tf file:<\/p>\n\n\n\n Add the password variable to the root variables.tf, with no default so OpenTofu refuses to run without it:<\/p>\n\n\n\n variable “db_password” { Set it through the environment rather than a .tfvars file that could end up committed:<\/p>\n\n\n\n export TF_VAR_db_password=’something-long-and-random’<\/p>\n\n\n\n Then in the root main.tf file, call the database module and add outputs for the hostnames, ports, and pool:<\/p>\n\n\n\n Managed databases on UpCloud get an assigned port, not 5432 or 6379. Mine came back as 11569 and 11570. Anything that assumes the default port will fail, which is why the ports are outputs rather than constants.<\/p>\n\n\n\n The hosts are hostnames rather than IPs. They resolve to private addresses, and those addresses can change during maintenance or failover while the hostname stays the same. Always hand the hostname to your application.<\/p>\n\n\n\n Notice the two passwords are handled differently. You supply PostgreSQL’s, and Valkey generates its own, so the module has to read it back out. Marking it sensitive keeps it out of terminal output, but it still sits in plain text in the state file. More on that in the security section.<\/p>\n\n\n\n Valkey also only accepts TLS connections. Configure your app with rediss:\/\/ or its TLS option, or it’ll fail to connect even with the right host, port, and password.<\/p>\n\n\n\n On UpCloud, PgBouncer isn’t a server you run. Connection pooling is built into managed PostgreSQL, and the provider exposes it as a resource, so the pool lives in the same module as the database.<\/p>\n\n\n\n database and username reference the other resources instead of repeating their names as strings. That’s what makes OpenTofu create the pool after the database and user exist. With plain strings, it could try to build all three at once and fail. Setting username also restricts the pool to that one user.<\/p>\n\n\n\n The default mode is transaction, the usual choice for web apps with short requests. A server connection is only held for the length of a transaction, so a small pool serves many clients. The trade-off is that anything relying on session state, like session-level prepared statements or advisory locks, won’t work reliably. Check your application before using it. session mode is the safe fallback.<\/p>\n\n\n\n The pool’s URI points to the same host as PostgreSQL, but a different port, and its database name is the pool’s name rather than the real database. Build your connection string from db_host and db_name, and you’ll connect directly, bypassing the pool without any error. Use the URI.<\/p>\n\n\n\n Run tofu apply.<\/p>\n\n\n\n Both services build in parallel, since neither depends on the other, and each takes five to ten minutes, and there’s no progress output during that time. Don’t interrupt it!<\/p>\n\n\n\n When it finishes:<\/p>\n\n\n\n OpenTofu lists pool_uri but hides its value. Read it with tofu output -raw pool_uri, and you’ll see the pool’s port and name in place of the direct ones.<\/p>\n\n\n\n In the control panel, open Databases. Both services should show as running with the private network attached. Then go back to your network’s Routing tab. You’ll find a new route to 100.125.24.0\/22 with the source “Network peering.” You didn’t create it, but UpCloud wires managed databases into your private network using the same peering mechanism we’ll use ourselves later.<\/p>\n\n\n\n UpCloud control panel showing the managed PostgreSQL and Valkey services running<\/em><\/p>\n\n\n\n The storage module creates an S3-compatible object storage service, a bucket, and a user with scoped access.<\/p>\n\n\n\n To set this up, create a modules\/storage\/variables.tf file:<\/p>\n\n\n\n Then add a modules\/storage\/main.tf file:<\/p>\n\n\n\n Find the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\n Finally, add a modules\/storage\/outputs.tf file:<\/p>\n\n\n\n Then in the root main.tf file, call the module and add outputs:<\/p>\n\n\n\n Object storage takes a region, not a zone, and they aren’t interchangeable.<\/p>\n\n\n\n A region like europe-1 spans many zones, and its private network attachment only works if your network’s zone is one of them. To see the options, read the upcloud_managed_object_storage_regions data source.<\/p>\n\n\n\n Each region lists its zones and a primary_zone, which is where the data physically lives. I picked europe-1 because its primary zone is fi-hel2, next to everything else in Helsinki.<\/p>\n\n\n\n A user with an access key can’t touch anything until a policy is attached. The policy is a standard S3-style IAM document, and the provider wants it URL-encoded, so jsonencode builds it, and urlencode wraps it.<\/p>\n\n\n\n The policy is scoped to one bucket rather than the whole service. Within that bucket, it allows s3:*, because applications that use multipart uploads break in hard-to-trace ways when the action list is too narrow. The description is immutable after creation, so changing it later replaces the policy.<\/p>\n\n\n\n If the arn:aws:s3 prefix looks odd, S3 is a protocol here, not a vendor. Any S3 client works against UpCloud once you point it at the endpoint, which is also why the access key IDs look like AWS ones.<\/p>\n\n\n\n The service exposes its endpoints as a set of objects, each with a type of private or public. The for expression in the output picks the private one. You’ll know it’s right because the hostname contains -private.<\/p>\n\n\n\n Run tofu apply. The service takes around ten minutes, with the bucket, user, key, and policies taking a second each once they exist.<\/p>\n\n\n\n When it finishes:<\/p>\n\n\n\n In the control panel, open Object Storage. You’ll see the service with the nextcloud-data bucket, and the nextcloud user with the nextcloud-bucket-access policy attached.<\/p>\n\n\n\n UpCloud control panel showing the object storage service<\/em><\/p>\n\n\n\n The file storage module creates an encrypted NFS share that every app server can mount.<\/p>\n\n\n\n First, add one output to modules\/network\/outputs.tf, so the share’s access list can use the network’s range instead of repeating it as a string:<\/p>\n\n\n\n output “cidr” { Then create a modules\/filestorage\/variables.tf file:<\/p>\n\n\n\n Then add a modules\/filestorage\/main.tf file:<\/p>\n\n\n\n Find the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\n Finally, add a modules\/filestorage\/outputs.tf file:<\/p>\n\n\n\n Then, in the root main.tf file:<\/p>\n\n\n\n encrypt = true can only be set when the storage is created. Add it later, and OpenTofu has to rebuild the whole service, so decide up front.<\/p>\n\n\n\n The share exists as soon as it’s created, but nothing can mount it without an ACL entry. The target here is the whole private network range rather than individual server IPs, so the ACL doesn’t need touching when you scale the servers. The trade-off is that anything on the subnet can mount it, which in this build is only the app servers.<\/p>\n\n\n\n Also notice the network block has no type field, unlike every other service in this build. File storage only attaches to private networks, and only one at a time.<\/p>\n\n\n\n File storage takes an address on your private network, just like a server, and which address it gets depends on what was created first. When I rebuilt everything from scratch, file storage came up before the servers and took 10.0.10.2, which pushed the servers to .5 and .6.<\/p>\n\n\n\n That’s one more reason nothing here hardcodes an IP. The mount target comes from the nfs_host output, and the servers mount <nfs_host>:\/nextcloud, which we’ll add to cloud-init when we wire everything together.<\/p>\n\n\n\n Run tofu apply, and when it finishes, you’ll see 3 added, plus the new outputs:<\/p>\n\n\n\n file_share = “nextcloud” Your address will differ.<\/p>\n\n\n\n In the control panel, open File Storage. You’ll see the service with the nextcloud share and one ACL entry for 10.0.10.0\/24 with read-write access.<\/p>\n\n\n\n UpCloud control panel showing the file storage service<\/em><\/p>\n\n\n\n The peering module creates a second private network and connects it to the first. Nothing in this build needs it to run.<\/p>\n\n\n\n It stands in for a management network, the kind of place you’d put monitoring or admin tools, and shows how to connect two networks without exposing either to the internet.<\/p>\n\n\n\n To set this up, create a modules\/peering\/variables.tf file:<\/p>\n\n\n\n Then add a modules\/peering\/main.tf file:<\/p>\n\n\n\n Find the complete main.tf file on GitHub here<\/a>.<\/p>\n\n\n\n Finally, add a modules\/peering\/outputs.tf file:<\/p>\n\n\n\n output “mgmt_network_id” { Then in the root main.tf file:<\/p>\n\n\n\n A peering on UpCloud only becomes active when it exists from both sides. That’s why there are two resources with the networks swapped. The mechanism is designed for connecting networks across different accounts, where each side has to agree independently. When both networks are yours, it feels redundant, but create only one, and you get a peering that shows as created and carries no traffic.<\/p>\n\n\n\n The ranges can’t overlap, which is why the management network uses 10.0.20.0\/24 against the app network’s 10.0.10.0\/24, and why the CIDR has been a variable since the network module.<\/p>\n\n\n\n If you ever remove a peering by hand in the control panel, it has to be disabled before it can be deleted.<\/p>\n\n\n\n Run tofu apply, and when it finishes, you’ll see 4 added and the new mgmt_network_id output.<\/p>\n\n\n\n In the control panel, open your app network’s Routing tab. You’ll see a route to 10.0.20.0\/24 with the source “Network peering” and the name nextcloud-app-to-mgmt.<\/p>\n\n\n\n Under the DHCP routes, the same route appears as auto-populated, with 10.0.10.1 as the next hop, which is how servers on the app network learn to reach the management network.<\/p>\n\n\n\n UpCloud control panel showing the app network’s routing table with a peering route to the management network<\/em><\/p>\n\n\n\n Every service now exists, but the app servers don’t know about any of them. This section passes the connection details into the servers through cloud-init, and mounts the shared file storage.<\/p>\n\n\n\n Add these to modules\/compute\/variables.tf<\/a>:<\/p>\n\n\n\n Find the complete variables.tf file on GitHub here<\/a>.<\/p>\n\n\n\n Then replace the user_data in modules\/compute\/main.tf<\/a>:<\/p>\n\n\n\n Then pass everything in from the root main.tf. The compute module block becomes:<\/p>\n\n\n\n The compute module now references outputs from three other modules, so OpenTofu builds the database, storage, and file storage before the servers. There’s no depends_on anywhere in this project. The references are enough.<\/p>\n\n\n\n The database connection is a single DATABASE_URL built from the pool URI, not a host and port. That’s deliberate. As the database section showed, connecting with the direct host bypasses the pool without any error, so the servers never receive the direct details at all.<\/p>\n\n\n\n Inside the heredoc, ${var.nfs_host} is HCL. OpenTofu replaces it before the script ever reaches the server. $(hostname) is shell and runs on the server at boot. If you need a literal ${…} in a script, for a shell variable with braces, escape it as $${…}, or OpenTofu will try to interpolate it and fail.<\/p>\n\n\n\n The share goes into \/etc\/fstab rather than a one-off mount command, so it survives a reboot. _netdev tells the system to wait for the network before mounting, which matters on a server whose only network is the private one. The mount runs after the package loop, because nfs-common has to be installed first.<\/p>\n\n\n\n user_data only runs at first boot, so changing it replaces the servers. Both get replaced in the same apply, which means a short outage while the new ones boot and pass their health checks. For a real deployment, look at create_before_destroy or roll the servers one at a time.<\/p>\n\n\n\n Run tofu plan first. You should see both servers replaced and the load balancer’s backend members updated to the new IPs, and nothing else. Then apply, and give it about five minutes before you curl the load balancer.<\/p>\n\n\n\n To confirm the wiring, open the console for either server and run:<\/p>\n\n\n\n cat \/etc\/app.env The first should show real values on every line, not ${var…}. The second should show the NFS share from your nfs_host mounted at \/mnt\/shared.<\/p>\n\n\n\n Building this was half the job because there were some things that caught me while I was running this.<\/p>\n\n\n\n The moment you change something in the control panel, the next plan shows it as drift, with OpenTofu proposing to put it back. That’s usually what you want.<\/p>\n\n\n\n When the platform changes something on purpose, like the gateway adding its route to the router, ignore_changes tells OpenTofu to leave it alone. And if a resource exists but isn’t in state, tofu import adopts it instead of recreating it.<\/p>\n\n\n\n By default, the state is a local file, and it holds every secret in this build in plain text. That’s fine while you’re learning. However, for anything shared, move it to a remote backend, which also stops two people from applying at once.<\/p>\n\n\n\n The repo’s root is a module that calls the seven submodules, and examples\/basic calls the root. That’s also how you’d separate environments: one root configuration each for staging and production, each calling the same module with its own name_prefix, CIDR, and plans, and each with its own state. Pin the module with ?ref=v1.0.0, so an update to the module never changes your production infrastructure by surprise.<\/p>\n\n\n\n Most of the security in this build isn’t about my configuration but about structure.<\/p>\n\n\n\n The app servers have no firewall rules, and that’s deliberate. UpCloud’s firewall filters public and utility<\/a> interfaces, and these servers have neither.<\/p>\n\n\n\n Rules on them would filter nothing. The only way in is the load balancer, which forwards to the backends you named on the port you configured.<\/p>\n\n\n\n Early in the build, my first server had a public IP, and I wrote firewall rules for it. Once the load balancer took over and the public interface came off, the rules had nothing left to guard.<\/p>\n\n\n\n Removing the exposure is a stronger guarantee than a rule, because a rule can be misconfigured and a missing interface can’t.<\/p>\n\n\n\n Every managed service follows the same pattern. The databases have public_access = false, object storage only exposes its private endpoint, and the file share’s access list only allows the private network’s range.<\/p>\n\n\n\n Marking a variable or output sensitive only keeps it out of the terminal and plan output. In this build, the database password, the Valkey password, the pool URI, and the object storage keys all end up in three other places:<\/p>\n\n\n\n NOTE<\/strong>: Don’t pass long-lived credentials through `user_data` in production. Use a secret-management system, or workload identity where the platform offers it, and have the application fetch credentials at runtime. The gain is rotation: the app can fetch a new credential each time without rebuilding the server, while one baked into `user_data` is replaced only when the server is.<\/p>\n\n\n\n For the state file, keep it in a remote backend, never in git, and encrypt it. OpenTofu can encrypt state natively from version 1.7, which is one of the features Terraform doesn’t have.<\/p>\n\n\n\n There’s no SSH into the servers, only the web console with the emailed root password. For regular access, the usual answer is a bastion host with a public IP and tight firewall rules, on the same private network.<\/p>\n\n\n\n Or skip access entirely: put everything in cloud-init and rebuild instead of logging in. That’s closer to the point of infrastructure as code anyway. A fix made by hand over SSH is a fix your code doesn’t know about.<\/p>\n\n\n\n And use an API sub-account for OpenTofu, not your main login. It can be restricted, and it can be revoked without locking you out.<\/p>\n\n\n\n Across both parts, we started with nothing and ended with a load balancer in front of two private app servers, managed PostgreSQL with connection pooling, Valkey, object storage, an encrypted shared filesystem, and a peered management network.<\/p>\n\n\n\n The GitHub repository<\/a> packages this build as a reusable module. The root of the repo is the module itself, and examples\/basic shows how to call it, which is the fastest way to stand up your own copy.<\/p>\n\n\n\n Everything here runs on a standard UpCloud<\/a> account, and the provider covers far more than we touched. If you’re still on Terraform, OpenTofu<\/a> is worth the switch, if only for native state encryption.<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n
type = string
sensitive = true
}<\/p>\n\n\n\n<\/figure>\n\n\n\nPorts and hostnames<\/h3>\n\n\n\n
Connection pooling<\/h3>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\nObject storage<\/h2>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\nRegions<\/h3>\n\n\n\n
Access policies<\/h3>\n\n\n\n
Private endpoint<\/h3>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\nFile storage<\/h2>\n\n\n\n
value = var.cidr
}<\/p>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\nEncryption<\/h3>\n\n\n\n
Access list<\/h3>\n\n\n\n
Mounting<\/h3>\n\n\n\n
nfs_host = “10.0.10.2”<\/p>\n\n\n\n<\/figure>\n\n\n\nPeering<\/h2>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\n
value = upcloud_network.mgmt.id
}<\/p>\n\n\n\n<\/figure>\n\n\n\nBidirectional connection<\/h3>\n\n\n\n
<\/figure>\n\n\n\nWiring it together<\/h2>\n\n\n\n
<\/figure>\n\n\n\n<\/figure>\n\n\n\n<\/figure>\n\n\n\nThe dependency graph<\/h3>\n\n\n\n
Through the pool<\/h3>\n\n\n\n
Two kinds of ${}<\/h3>\n\n\n\n
The mount<\/h3>\n\n\n\n
Replacing servers<\/h3>\n\n\n\n
df -h \/mnt\/shared<\/p>\n\n\n\nManaging the infrastructure<\/h2>\n\n\n\n
Drift<\/h3>\n\n\n\n
State<\/h3>\n\n\n\n
Modules and environments<\/h3>\n\n\n\n
Security<\/h2>\n\n\n\n
Firewall rules<\/h3>\n\n\n\n
Where the secrets end up<\/h3>\n\n\n\n
\n
Access<\/h3>\n\n\n\n
Wrapping up<\/h2>\n\n\n\n