Customer-facing applications
Web front ends, APIs and the services behind them, placed on a network your team can describe end to end.
Before launch, agree how traffic enters, who holds access and how data is restored.
Explore the architectureCompute, networks & operationsExplore One console for every workload.
One console for every workload.
Clear owners for every layer.
Run virtual machines, containers and functions with the networks, DNS records and access rules that connect them. Your team plans the environment together and operates it from the same place.
Networking / Overview
Your network, in context.
An operating view of application networks, subnets and access.
Networks02
Subnets03
Rule sets02
application-net
WebServicesData
| Network | Address space | Purpose | State |
|---|---|---|---|
| application-net | 10.42.0.0/16 | Business applications | Configured |
| development-net | 10.43.0.0/16 | Development | Configured |
Built on familiar open-source foundations
- QEMU / KVMVirtualization
- PodmanOCI containers
- LinuxOperating systems
- Authoritative DNS
The platform
Every layer of the application.
Managed in one place.
Compute for each part of the application, the networks and names that connect it, and the tools your team uses to run it day to day.
Compute
Virtual machines
Your operating system. Your environment.
Runtime
Containers
Bring an OCI image. Configure your service.
Runtime
Functions
A focused runtime for request-driven code.
Connect
Networking
Define how your workloads connect.
Connect
DNS & certificates
Connect names, records and service identity.
Operate
Cloud Shell
A terminal workspace inside your browser.
Built around your workload
Start with the workload
you already run.
Good infrastructure follows the software, its dependencies and the people who keep it running. These are the patterns teams bring to us most.
Internal business systems
A Linux environment built around the packages and connections your organisation already depends on.
Review credentials, network boundaries and who maintains the guest.
Explore the architectureDevelopment and staging
A separate runtime per project for building and testing changes before they reach production.
Keep test data and secrets apart from production.
Explore the architectureArchitecture & operations
See how every service connects.
Before anything goes live.
A web application is rarely one machine. Map the entry point, the internal services and the data they share, then build the environment to match.
WEB APPLICATIONArchitecture example
app.example.comService entry point
Application network
Web applicationVirtual machine
01API serviceContainer
02DatabaseSelf-managed on a VM
03Ecocloud consoleResources / Configuration / Operations
Draw the network first
Place each service on a subnet, decide which routes exist and write the firewall rules before anything is exposed.
Separate traffic from data
Keep the public entry point apart from internal APIs and databases. Review credentials and guest configuration with the people who own them.
Hand over to operations
Service state, console access and supported logs become part of the team's routine from the first day.
Shared responsibility
Know who owns each layer.
Before the first deploy.
Ecocloud runs the resources. Your team runs what is inside them. Agree on the line early and write it into your operating plan.
| Layer | Ecocloud provides | Your team owns |
|---|---|---|
| Compute | Provisioning and lifecycle of supported virtual machines, containers and functions | Guest operating system, packages and application code |
| Network & DNS | Networks, firewall rules and DNS records configurable in the console | Which connections are allowed and how each service is exposed |
| Access | Console access and service configuration | Credentials, keys and who on the team can use them |
| Data | Storage included in the selected configuration | Backups and recovery procedures that have been tested |
| Cost | Published offers, billing units and budget alerts | Choosing configurations and acting on spending alerts |
A working model for planning. The selected offer and the applicable agreement define service commitments.
How the platform is built ↗Commercial clarity
Published prices.
Reviewed before you order.
Compare current configurations by resources and billing unit. The full configuration and its cost are shown before an order is placed.
Loading published offers…
From evaluation to operation
Move one workload first.
Expand once it is proven.
A practical evaluation follows a real application through configuration, testing and recovery, so the second workload starts from experience.
Map the application
List runtimes, dependencies, where data lives and who needs access.
Deployment patternsAgree on ownership
Decide who handles guest updates, credentials, monitoring and recovery.
Responsibility modelValidate a first release
Deploy a small configuration, send representative traffic with test data and rehearse the rollback.
Getting started guideOperate, then expand
Bring logs, backups and alerts into the routine. Move the next workload once the first one is stable.
Plan it with our team
Explore & learn
A practical place to start.
Solutions
Architecture patterns
Follow application, development and database patterns, with a staged approach to migration.
InfrastructureUnderstand the platform
See how workload runtimes, networks and the control plane fit into an operating environment.
DocumentationOperate your services
Find service configuration, access tools and billing information in the customer console.
Your infrastructure. Connected.
Bring us one workload.
Plan it with our team.
Tell us about the application, its dependencies and the team that runs it.
Plan the environment and its owners from the first conversation.