Modular SPA UI Plan for Hosting Services Dashboard

Overview of Requirements and Goals

The Prince George–based tech company runs a ConcreteCMS v9 website and offers game hosting (using an AMP panel), web hosting on an Nginx/PHP-FPM stack, and VPS hosting. The objective is to build a single-page application (SPA) user dashboard – in a developer-friendly style – that will grow into a full “cloud” portal. Key requirements include:

• Unified Login: Users sign up and log in via ConcreteCMS’s native system. The dashboard will recognize their ConcreteCMS user session and group memberships for access control.

• Modular Services: The dashboard is composed of modules (web components) corresponding to services (Game Servers, Web Hosting, VPS, Billing, etc.). A user’s view is populated only with the modules for the services they have subscribed to.

• Self-Service Provisioning: Initially, users can deploy predefined packages for each service (e.g. specific game server sizes, preset hosting plans, fixed-size VPS) with minimal customization. In the future, allow custom configurations and advanced provisioning (similar to selecting instance specs on a cloud platform).

• Billing Integration: Use Zoho Invoice’s API for automating subscription invoicing and payments. The system should handle account creation in Zoho, invoice generation for new orders (and recurring invoices for subscriptions), and reflect payment status in the portal.

• Scalability & Evolution: Design the UI/UX and architecture to accommodate future growth – more service types, more customization options, possibly team accounts – without major rework. The portal should be built on modern, maintainable tech to support ongoing R&D and integration with local infrastructure upgrades.

This plan outlines the recommended front-end tech stack, user experience flow, backend provisioning logic, and billing integration strategy. It draws inspiration from industry-leading developer portals (AWS, DigitalOcean, etc.) and leverages open-source tools to align with the company’s local hosting infrastructure and growth plans.

Inspiration from Developer Portals and Cloud Panels

To deliver a developer-style dashboard, we take cues from established cloud control panels (AWS, DigitalOcean, Rackspace, etc.):

• At-a-Glance Summary: Provide an overview of all the user’s resources on the dashboard home. DigitalOcean’s redesigned dashboard, for example, gives “visibility into active resources… and key account-related information… at a glance”​

  digitalocean.com

  . Similarly, our dashboard’s main page will show active game servers, websites, VPSes, and a quick billing summary so users can grasp their usage immediately.

• Clear Navigation: Use a sidebar or top navigation that lists the major sections (Game Hosting, Web Hosting, VPS, Billing, Support). This echoes the approach of cloud portals like AWS, which list services, or Rackspace’s Cloud Panel which provides a “unified web-based interface” for all products​

  docs-ospc.rackspace.com

  . Navigation should be logical and group related items together (e.g. all hosting services under a section) for easy scanning.

• Permissions-Based Content: Only display what the user has access to. In Rackspace’s cloud panel, “users who do not have permission to use a feature do not see that feature in the Cloud Control Panel.”​

  docs-ospc.rackspace.com

  We will adopt this principle via ConcreteCMS user groups – e.g. if a user isn’t in the “VPS Customers” group, the VPS module or menu item won’t even show up. This keeps the UI clean and avoids confusion, only highlighting relevant options to each user.

• Consistent Look & Feel: Developer portals favor a clean, utilitarian design – neutral colors, clear typography, and simple icons – to ensure information density doesn’t become overwhelming. We should maintain visual consistency across modules (e.g., similar card layouts or tables for listing resources) and use a limited, high-contrast color palette for clarity. Interactive elements (buttons, toggles) should behave uniformly across the app.

• Quick Actions & Feedback: Provide obvious ways for users to take action on resources (e.g. a “Create New Server” button in the Game Hosting section, “Start/Stop” controls on a VPS card). Actions should trigger feedback – e.g. a status indicator or message – so users know the command was received. Cloud panels often show transitional states (“starting…”, “provisioning…”) to indicate progress, which we will emulate.

• Reference Resources: Include easy access to support and docs. For example, the top nav can have links to a knowledge base or API docs, similar to how DigitalOcean’s console surfaces links to tutorials and support for users’ self-help​

  digitalocean.com

  . This reinforces a developer-friendly vibe, anticipating that users may want to troubleshoot or extend their services.

By studying these patterns, we ensure our dashboard balances simplicity and power. The initial view will highlight what the user has and can do next, without clutter. As the user digs into a section, more detailed controls specific to that service are available, much like how AWS or DigitalOcean progressively reveal options.

Web Component–Based SPA Framework

To build a modular front-end, we will use Web Components as the foundation. Web components allow us to create custom HTML elements encapsulating their functionality and styling, which is perfect for a widget-like dashboard. The benefits and approach are:

• Framework Choice – Lit or Similar: We recommend using the Lit library (LitElement) to build the components. Lit is a lightweight library that simplifies creating web components with a minimal API. Lit components are standard custom elements, meaning ConcreteCMS (or any CMS) can output them like regular HTML and they’ll “just work” in the browser​

  lit.dev

  . Lit’s use of Shadow DOM ensures each component’s styles are scoped to itself, preventing CSS conflicts between modules or with ConcreteCMS’s theme​

  lit.dev

  . This isolation is important for maintaining modularity – e.g., the game server component’s UI won’t accidentally break the VPS component’s UI.

• Independence and Interoperability: By embracing web standards, we avoid binding the front-end to any heavy framework that could cause lock-in. “By embracing Web Components, Lit minimizes lock-in and promotes maintainability”, allowing us to update or migrate one component at a time without disrupting others​

  lit.dev

  . This is ideal for an evolving portal: if in the future one module needs a complete overhaul, we can rewrite that web component (or even replace it with another implementation) independently.

• Modular Development: Each service module (e.g., <game-server-panel>, <web-hosting-panel>, <vps-panel>) will be a self-contained component. They can be developed and tested in isolation, then integrated into the SPA. This aligns with a micro-frontend philosophy – different pieces of the UI can be built separately, possibly by different team members, and then composed into the dashboard. It also means we can lazy-load components as needed. For instance, the code for <vps-panel> might only load when the user navigates to the VPS section, improving initial load performance of the dashboard.

• Integration with ConcreteCMS: We can package our web components and include their script bundle in ConcreteCMS pages. Concrete v9 can serve the JS/CSS assets (perhaps via a theme or addon package). Because the components are just custom elements, Concrete’s PHP can render a placeholder element (like <game-server-panel user="${uid}"></game-server-panel>) on the page, and the web component will take over rendering its internals. The components can receive initial data via HTML attributes or a JSON script embedded in the page by Concrete (for example, a list of the user’s services), or they can fetch data on their own once mounted.

• Alternate Frameworks: If the team has expertise in frameworks like Vue or React, those could be used to build an SPA as well – ConcreteCMS even provides examples of using Vue.js within a block for dynamic functionality​

  documentation.concretecms.org

  . However, using Vue/React as a monolithic SPA might conflict with the “web component” modular approach, unless we wrap each part as a web component. Notably, Vue 3 and Angular can compile components into custom elements (Angular’s “Elements” feature), so one approach could be to use Angular internally for each module and output it as a web component. But this may add complexity and size. Given our goals, Lit (or even just vanilla Web Component APIs with helper libraries) offers a clean integration with fewer dependencies. It’s also more lightweight than loading a full framework runtime.

• UI Library and Styling: To accelerate development, we can leverage an existing design system implemented as web components. For example, Shoelace is a library of pre-built web component UI controls (buttons, dialogs, tabs, tooltips, etc.) that works with Lit and other frameworks. By using such a library, we ensure consistent styling and behavior for common UI elements without reinventing them. This helps maintain a professional look across modules. We’ll also define a simple style guide (colors, spacing, typography) so that custom elements we build all adhere to the same design language – critical for a unified feel.

In summary, web components provide the modularity and encapsulation needed for this dashboard. We’ll build our SPA as a collection of custom elements (likely with LitElement for convenience). These will integrate smoothly into ConcreteCMS’s pages (the CMS can output them like any HTML since “Lit components are standard custom elements… output them from your CMS… they just work”​

lit.dev

). This setup lets us enhance the site with a modern reactive app while still leveraging Concrete’s backend for data and auth.

Integration with ConcreteCMS (Frontend–Backend Architecture)

The backend architecture will bridge ConcreteCMS (PHP/MySQL) with the front-end SPA (JavaScript) via secure AJAX/REST calls. Key points of the integration:

• Single-Page Application Shell: We will create a ConcreteCMS Single Page (in Concrete terminology) for the dashboard. For example, a page at /account/dashboard that is only accessible to logged-in users. This page’s view will include the initial HTML structure of the SPA (perhaps a loading screen or the basic layout container) and the compiled JS for our web components. ConcreteCMS can conditionally include modules or data based on the user: e.g., embed a JSON listing the user’s service entitlements or group membership, which the SPA can read on startup to decide which components to render.

• Leveraging ConcreteCMS User System: Authentication is handled by ConcreteCMS’s native login. Once logged in, the user’s session cookie will apply to AJAX requests as well. We can use Concrete’s built-in tools to require login for the dashboard page and any AJAX endpoints. Concrete v9 introduced a “full built-in REST API”​

  concretecms.com

  , which we can potentially extend. For instance, we might enable Concrete’s OAuth2 if we ever allow external apps, but within our SPA, it’s simpler: the SPA calls endpoints on the same domain, and ConcreteCMS checks the session (or we issue a token upon login).

• Custom Dashboard API Endpoints: We will implement backend endpoints (in PHP) for the SPA to fetch and manipulate data. There are a couple of approaches:

  • Utilize ConcreteCMS REST API capabilities: Concrete has core API endpoints (for users, etc.)​

    documentation.concretecms.org

    . We may extend this by adding custom endpoints (Concrete allows creating API routes in packages). For example, an endpoint /api/dashboard/listServices that returns JSON of the current user’s subscribed services and their status. Endpoints for actions like /api/gameServers/start could accept a server ID and trigger the start action.

  • Alternatively, use Single Page Controller Actions or Block Actions as in traditional Concrete AJAX. For example, the Vue integration tutorial uses a block controller action_submit to handle an AJAX form post​

    documentation.concretecms.org

    . We can do something similar: a controller for the dashboard page might have methods like action_getServerList that return a JSON Response. Concrete provides utilities for JSON responses (e.g., $app->make(ResponseFactoryInterface::class)->json($data) as seen in the tutorial)​

    documentation.concretecms.org

    . This is quick to set up and leverages Concrete’s security (including CSRF tokens if we use form posts). Since we control both front and back, we can also have the SPA include Concrete’s CSRF token in requests if needed (the token can be printed in the page by PHP).

• Data Flow Example: When the SPA mounts, it could call a unified endpoint (like /api/user/services) to get an object containing all relevant info: which services the user has, IDs/names of each, and maybe initial status. The Concrete controller will gather this by checking the user’s groups or an internal service registry (see “Provisioning Backend” below for how we track service instances). The response is JSON, which the SPA then uses to render the appropriate modules (e.g., if it says user has 2 game servers, the SPA will create two game server status cards).

• AJAX Communication and Security: We will primarily use JSON over AJAX for SPA–server communication. This is in line with modern REST practices and what Concrete’s API uses (JSON format, likely similar to how Proxmox’s API is JSON-based​

  pve.proxmox.com

  ). All requests will be on-domain (e.g., https://our-site/api/...), which means the Concrete session cookie authenticates them. We will ensure to check user permissions on each request server-side (never trust just the UI state). If additional protection is needed, we can include Concrete’s CSRF tokens for state-changing requests (Concrete provides a $token = $app->make('token') service to generate/validate tokens​

  documentation.concretecms.org

  ). For read-only GET requests, the session check should suffice.

• Using Concrete Entities vs. External DB: We might extend Concrete’s database to store service data (e.g., a “UserServices” entity that records which packages a user has, and maybe external IDs like VPS ID or game server ID). This can help in quickly querying what a user owns. Alternatively, we rely on external systems (Zoho for billing info, the game panel for game server list, etc.) and aggregate that on the fly. A hybrid approach could be best: maintain a minimal internal record of provisioned services for each user (so the portal is the central source of truth for what exists), and use external APIs to fetch live status or perform actions.

• Page Updates vs. SPA Routing: As an SPA, we prefer to load the dashboard once and then update content dynamically. We can implement internal routing (using the History API or hash routes) for sub-pages like “Game Hosting -> Details of Server 1”. These would not cause full page reloads. ConcreteCMS can have a single “Dashboard” page handle all these via the SPA’s client-side router. This means we might need to configure Concrete to not conflict with URLs under /account/dashboard. For example, using hash-based routing (e.g. /dashboard#vps/123) avoids server-side routing entirely. If we want nice URLs (like /account/dashboard/vps/123), we could set up a Concrete route to funnel everything after /dashboard to the same page. This might be achieved via a URL rewrite or a custom route that catches /dashboard/*. Simpler for now is to use hash routes or manage it wholly on the client side.

• Concurrency and Async Considerations: Some operations (like provisioning a new server) can take time. The frontend will likely initiate a request (e.g., “create new VPS”) via AJAX. The backend will respond immediately with either a success (accepted) or error. The actual provisioning might happen synchronously within that request or asynchronously. For better user experience, we lean toward asynchronous jobs (so the user isn’t stuck with a loading spinner for a long time or a timeout). We could implement a job queue where the request to create a VPS puts a job in a queue and returns a job ID. The SPA can then poll an endpoint like /api/jobStatus/{id} to see if it’s done, updating the UI when ready. In early stages, if we choose to do some actions synchronously (because maybe they complete in a few seconds), we will show a loading indicator and then refresh the relevant data once the call returns.

• ConcreteCMS as an Application Backend: It’s worth noting that ConcreteCMS v9 is more than just a CMS – with its new API and MVC tools, we can treat it as our application backend. We can define custom Classes for things like provisioning tasks, use Concrete’s database connection for storing our own records, and even use package controllers to handle any routing. Essentially, ConcreteCMS provides user management (with groups, which we heavily use for permissions) and a framework to build out the needed backend logic in PHP. The built-in REST API and OAuth​

  documentation.concretecms.org

  features indicate we could even expose APIs to external applications if needed (e.g., if someday a mobile app is built, it could use the same API). For our SPA, we’ll stick to internal calls, but it’s good to know the platform supports a headless mode for future expansion.

In summary, the SPA will communicate with ConcreteCMS through AJAX JSON endpoints. We’ll protect these with Concrete’s auth and possibly CSRF tokens. Concrete’s role is to orchestrate data between the front-end and the various back-end services: it will receive a request from the SPA, authenticate and authorize it (user in correct group?), then invoke the appropriate provisioning logic or Zoho API call or database query to perform the action, and finally return a response. This separation keeps the front-end clean (just UI/UX) and the heavy lifting on the server side, as is appropriate for a secure hosting dashboard.

User Experience Flow and Dashboard Structure

This section describes the end-to-end user flow and how the dashboard is structured for an optimal user experience:

• Registration & Onboarding: Users will register through the ConcreteCMS site’s normal registration (e.g., an email and password, with email verification if configured). Upon registration, they might start with no services. We can have ConcreteCMS automatically assign new sign-ups to a general “Customer” group. If desired, we could implement an onboarding tour in the dashboard SPA to welcome new users and guide them to order services.

• Service Subscription Process: To get services, a user will either purchase them through the site’s store interface or, in the fully integrated vision, directly via the dashboard:

  • We can add an “Order Services” or “Add New Service” button on the dashboard. Clicking this could open a module or modal where the user can choose a service category (Game Server, Web Hosting, VPS) and then select from available packages. For example, under VPS, they might see “Small – 2 CPU, 4GB RAM, 50GB SSD – $X/month” and so on.

  • Once a package is selected, the system will trigger the billing workflow (discussed in the Billing section) and then provisioning. For the user flow, assume they complete checkout/payment – the new service will then appear in their dashboard.

  • The user is added to the corresponding ConcreteCMS group for that service (perhaps this group assignment happens post-payment when we provision). E.g., buying a game server adds them to “Game Hosting Customers” (or a more specific group if we segment by game type).

• Dashboard Access: After login, the user can navigate to their dashboard (we’ll place a prominent link in the site header like “My Cloud Dashboard” or under an account menu). This loads the SPA. The initial dashboard screen (the Overview) will welcome the user (by name) and display a summary of their services:

  • For each service type the user has, show a card or section. For example:

    • Game Servers: “You have 2 game servers running.” List their names or game types, and maybe their current status (running/stopped). Possibly include a quick “Manage” link.

    • Web Hosting: “You have 1 website hosting plan.” Show the primary domain or site name, and maybe usage (e.g., “Using 20% of 10GB storage” if available).

    • VPS: “You have 1 VPS instance.” Show something like the hostname or IP, status (up/down), and resource snapshot (CPU/Disk usage).

    • Billing: Show current account balance or next invoice date if applicable, or simply a link like “View your invoices”.

  • If the user has no services of a given type, we could either hide that section or show a call-to-action: e.g., if they have no VPS, an empty state card might say “Need a virtual server? [Click here to deploy your first VPS]”. This can encourage upsells. However, we’ll do this tactfully to maintain the dashboard’s focus (perhaps an “Add Service” button as mentioned, instead of multiple prompts).

• Navigation & Menus: A left sidebar menu (persistent as the user navigates within the SPA) will list the main sections:

  • Dashboard Home – the overview page described above.

  • Game Hosting – section for game server management.

  • Web Hosting – section for website hosting management.

  • VPS Hosting – section for VPS management.

  • Billing – section for billing history, payments, etc.

  • Support – possibly a link or module for support tickets or FAQs (this could simply link out to a support page initially).

  • We will implement the menu such that only relevant sections appear. For example, if a user has no game servers and we decided not to show empty prompts, we might omit “Game Hosting” from the menu entirely. This ties back to permission-based UI: the user’s groups or service list determines menu items. This dynamic menu can be driven by the data from the backend (e.g., the JSON returns hasGame:true/false).

  • The menu should remain logical even as features grow. If many items accumulate, grouping or collapsible sections can be used. However, given the current services (3 product types + billing), a simple list is sufficient.

• Service Modules (Detailed Pages): Each main section (Game, Web, VPS, Billing) will be handled by a dedicated web component or set of components. Here’s what users can do in each:

  • Game Hosting Module: When clicking “Game Hosting” in the menu, the user sees a list of their game server instances. This list could be a set of cards or a table:

    • Each entry shows identifying info (server name or ID, game type, perhaps location if that matters, status – running or stopped).

    • Basic controls on each card: Start, Stop, Restart buttons for the server (with icons for clarity). These trigger AJAX calls to the backend to command the AMP panel to perform the action.

    • A Manage/Details button: Clicking an instance could reveal more details, either via an expandable panel or navigating to a sub-page /dashboard/game/ServerID. Details might include: configuration (slots, memory), a live console view (if feasible via API or perhaps an embedded console from AMP), and maybe usage stats (players online, CPU/RAM if available). Initially, we might keep it simple: just show a log or status output area. We could integrate with AMP’s console via a web socket or iframe if AMP supports it.

    • If multiple game types are supported, we can show an icon or label for the game (Minecraft, CS:GO, etc.). Also, if the user can have multiple servers, ensure it’s clear which is which (allow them to set a custom name or label at creation time).

    • An Add Game Server action: If our system allows multiple game servers, provide a button to deploy a new one (leading to the order workflow for game servers).

    • The UI pattern here is akin to cloud VM lists (like AWS EC2 instances list or DigitalOcean Droplets list), but tailored to game-specific info (like a “players” count if relevant). Everything should be real-time updated when possible – e.g., if a server is starting, show a spinner or status “Starting…” and refresh the status.

  • Web Hosting Module: Clicking “Web Hosting” shows the user’s websites or hosting accounts. If the subscription is one site per plan, this might show just one entry with details:

    • Information like domain name, root folder, PHP version, and usage stats (disk, bandwidth) can be displayed.

    • Controls: Possibly a “Manage Site” button that could reveal options such as:

      • File Manager: open a file manager to browse/upload files (this could be a separate component or an integrated third-party tool).

      • Database Manager: link to phpMyAdmin or adminer for database access (we can set up a secure phpMyAdmin instance and auto-login the user to their DB via a token).

      • Config settings: maybe allow toggling PHP settings or enabling SSL. Initially, these might not be user-exposed if using a preset stack, but later could be added (or simply instruct to contact support for advanced changes).

    • If the hosting plan allows multiple add-on domains or sites, we’d list them. If multiple, an “Add Domain” button would be present.

    • The web hosting panel might integrate with whichever system we choose (e.g., if using ISPConfig, we might fetch data through its API like domain, ftp user, etc.). However, to keep things straightforward for the user, we’ll present a simplified view – they shouldn’t need to know about the underlying panel.

    • Essentially, this module functions somewhat like a mini cPanel. In early stages, we may keep it minimal (show credentials and basic info), and over time introduce more self-service (create email accounts, add subdomains, etc., if the automation supports it).

  • VPS Hosting Module: The “VPS Hosting” section lists the user’s virtual servers:

    • Each VPS entry shows details such as: hostname (or an assigned name like “VPS #123”), primary IP address, current power status (running, stopped), and resource allocation (RAM, vCPU, disk). If we have usage monitoring, we can show current CPU% or a small graph thumbnail.

    • Controls on each VPS: Start, Shutdown, Reboot. Perhaps Open Console (which could pop up a noVNC console for direct access).

    • Manage details: clicking the VPS could show more info: the OS image it’s running, credentials (e.g., the root password or key provided at creation), and allow actions like Rebuild (reinstall OS) or Resize (if we plan to allow upgrading plan – this might be future, resizing typically involves billing change).

    • If using Proxmox API, we can also surface snapshots or backups if we implement those: e.g., list available snapshots and allow restore. That might be an advanced feature for later.

    • Provide an Add VPS button if multiple are allowed (leading to the order form for a new VPS deployment).

    • Overall, this module is analogous to something like DigitalOcean’s Droplets page or AWS’s EC2 dashboard but simplified. It should give users enough control over their VM without overwhelming them. We will ensure dangerous actions (like delete/destroy VPS) have confirmations and perhaps are initially done via support until automated safely.

  • Billing Module: The “Billing” section focuses on account financials:

    • It will list invoices and payments. Using Zoho’s API, we can fetch the user’s invoices. Present them in a table with columns: Invoice #, Date, Amount, Status (Paid/Unpaid). The user can click an invoice to view details. We might provide a link to download the PDF (Zoho can provide an invoice PDF link).

    • Show upcoming charges: for example, “Next invoice on Aug 1, 2025 for Game Server Basic – $10”. We know this by looking at recurring profiles or the billing cycle information from Zoho.

    • Payment method info: if we have stored info (Zoho Invoice itself might not store payment methods unless integrated with Zoho Subscriptions or Stripe), we might just say “Your invoices are due upon receipt. Please ensure timely payment via the invoice links sent to your email.” If in future we integrate direct payments, this section could allow adding a credit card or initiating payments on open invoices.

    • Possibly display current balance or credits if the company uses account credit. Zoho API could tell if an invoice is overdue – we can highlight that (“Overdue” in red and maybe a warning icon).

    • A Pay Now capability: If Zoho is set up with a payment gateway, we could embed a payment link or even handle payment via Stripe integration in-app and then mark the invoice paid via API. Initially, it might be simpler to redirect users to the Zoho-hosted payment page for an invoice (Zoho can generate a permalink for the invoice).

    • Subscription management: list active subscriptions (services) with their renewal dates and amounts. This ties the billing info back to services. E.g., “Game Server (Basic) – $10/month – Next bill on 2025-08-01”. This reassures users what recurring costs to expect. We can derive this from the recurring invoice schedule in Zoho or from our internal package info.

    • Billing Settings: allow updating billing address (we can push that to Zoho via API), and perhaps an option to cancel a service (which would ideally trigger a cancellation workflow: end the service at period end and stop recurring invoices).

• Support & Account Management: Although not explicitly requested, a comprehensive portal often includes a support module (to open tickets, chat support, etc.) and account settings (update profile, change password). We might not build a full ticketing system now, but at minimum provide contacts or links. Since ConcreteCMS manages user profiles, a link back to Concrete’s profile edit page can be given (or that could be integrated into the SPA as a form that updates Concrete via AJAX).

• Responsive Design: We should ensure the SPA layout is responsive. While most developers use desktops, some may check statuses on mobile. Using flexible web components and CSS grid/flexbox, we can make the dashboard collapse the sidebar into a hamburger menu on small screens, stack cards vertically, etc. This is a standard best practice (the dashboard should “function well across various devices” as a core design requirement​

  niamh-oshea.medium.com

  ). ConcreteCMS v9 themes are typically Bootstrap 5, so aligning with that grid system or using a CSS framework could help.

• Visual Dashboard Best Practices: We will apply general dashboard UX best practices:

  • Emphasize clarity over complexity – show key info up front, hide secondary info under collapsible sections or separate pages to avoid clutter​

    niamh-oshea.medium.com

    .

  • Use visual hierarchy – e.g., on the overview page, use larger text or cards for overall resource counts, and smaller sections for finer details​

    niamh-oshea.medium.com

    . Important alerts (like an overdue invoice or a server down) could be highlighted at the top in a banner or with attention-grabbing icons.

  • Maintain consistency in UI controls and terminology across modules, so users feel they are in one coherent application.

  • Keep interactions intuitive – e.g., clickable rows or gear icons for settings should be standard. Provide tooltips or help icons for any non-obvious metrics.

  • Ensure the design can scale. As one best-practices article notes, “design with scalability in mind so the dashboard can accommodate future expansions without becoming overwhelming.”​

    niamh-oshea.medium.com

    . For us, this means the layout should handle if a user eventually has, say, 10 VPS or 20 websites – the UI should still be navigable (perhaps pagination or grouping for large numbers). Also, as more service types are added, the menu should remain manageable.

By mapping out this user flow and structure, we create a cohesive user experience. A developer logging in will feel they have a control panel much like they’d expect from a larger cloud provider, tailored to this company’s offerings. They can quickly find their services, manage them, and see their billing info. As the portal grows, this structure will accommodate new features (for example, if a new “Database Hosting” service is launched, we’d add a menu item and a module for it, following the same patterns). The modular design ensures we can insert those seamlessly.

Service Provisioning Backend Logic

A critical aspect of this portal is automating the provisioning and management of services (Game servers, Web hosting accounts, and VPS). Here we outline how each type of service can be provisioned using available tools or scripts, and how the portal will interface with those systems:

Game Servers Provisioning (Using AMP)

For game hosting, the company uses AMP (Application Management Panel) by CubeCoders. This is a robust game server control panel with a web UI and automation capabilities. We will leverage AMP’s features via its API:

• AMP API Integration: AMP exposes a RESTful API (with endpoints to create and manage game instances). In fact, you can add “/API” to an AMP panel URL to see its API specification​

  discourse.cubecoders.com

  . Using this API, “you can use [it] to control pretty much everything that you can do manually via the web interface including deployment of new servers”​

  spigotmc.org

  . Our portal backend will act as an API client to AMP:

  • To provision a new game server, the portal (ConcreteCMS PHP side) will send an API request to the AMP instance (or its ADS module) to create a new server instance. This may involve calling something like CreateInstance with parameters for game type, memory, etc., then SetConfig to apply specific settings (as suggested by the AMP developer on their forum)​

    discourse.cubecoders.com

    . We can automate the entire setup: e.g., choose the game (Minecraft, etc.), set the version, allocate resources, and start the server. AMP’s API allows specifying config like version or server name via calls such as SetConfig and Update()​

    discourse.cubecoders.com

    .

  • Assigning to User: We have two approaches:

    1. Create all game servers under a master AMP account and control them via the API. In this case, the user never directly logs into AMP; they use our portal for everything. This centralizes control but means if the user wanted more advanced control, we’d have to build it or provide limited AMP access.

    2. Create a corresponding user account in AMP for the customer and give them access to their instance. AMP supports role-based permissions and can restrict what actions a user can take. For example, AMP can give a user console and start/stop access but restrict file management based on their rank/role​

       discourse.cubecoders.com

       ​

       discourse.cubecoders.com

       . If we choose this route, when a new game server is provisioned, the portal can use the AMP API to also create a user (if not already) and set the instance’s ownership to that user. The benefit is that down the line, if we want to let advanced users access the full AMP panel, we can do so (they would have a separate login to AMP with limited permissions).

    • In either case, for now we’ll likely use the portal as the primary interface. We just need to be mindful of AMP licensing: selling game servers typically requires an AMP enterprise license​

      discourse.cubecoders.com

      , which presumably the company has.

  • Server Actions: For existing servers, the portal will call AMP API endpoints to start, stop, restart the server. These are likely straightforward (e.g., an API call like SendConsoleCommand or specific power controls). We can also query status by calling an AMP endpoint that returns whether the server is running.

  • Console Output & Advanced Controls: In a fully featured game panel, users can see console logs, manage configs, etc. Initially, we might implement just the basics (start/stop and maybe view last N lines of log). AMP’s API could let us fetch logs or we might embed a console via a websocket proxy. This is a stretch goal; at minimum, we ensure the user can control the power state and know how to connect to the game (display the IP and port of their server).

  • Predefined Packages Mapping: Since we offer predefined game hosting packages (likely defined by RAM, player slots, and specific games), the portal will translate a package choice into the appropriate API calls. For example, “Minecraft Basic” might mean create an instance with 2GB RAM and Minecraft Java latest version. These values will be set via the API as part of provisioning (the GetSettingSpec API in AMP can tell us what config keys to set for a specific game module​

    discourse.cubecoders.com

    ​

    discourse.cubecoders.com

    ).

  • Alternate/Advanced Option: The company can consider using Pterodactyl, an open-source game server panel, which also has a well-documented API and is widely used in game hosting. Pterodactyl’s API similarly allows creating servers from “eggs” (game templates) and managing them​

    spigotmc.org

    . While the current system is AMP, we mention Pterodactyl as an R&D consideration: it’s free (no license cost per server) and has a large community. If customization needs outgrow AMP’s capabilities or licensing becomes an issue, migrating to Pterodactyl could be explored. For now, we proceed with AMP as it’s in place.

• Automation Scripting: To integrate AMP’s API with ConcreteCMS, we might write a PHP service class (or even use a small framework like Guzzle for HTTP calls). There might also be existing API wrappers (for example, a Python package ampapi exists​

  pypi.org

  , but for PHP we’ll likely craft our own or use cURL). Each game-server-related endpoint on our portal will invoke this class. Logging and error handling are important – e.g., if AMP returns an error (like no capacity or invalid config), we should catch that and inform the user or admin.

• Lifecycle: The portal should also handle de-provisioning: if a user cancels a game server, we call the AMP API to delete the instance (or archive it). We should also remove their AMP user or permissions if we created one. Similarly, suspensions (for non-payment) could be handled by stopping the server or locking the user in AMP. These rules will tie into billing status (discussed later under Billing Automation).

By connecting to AMP’s API, the portal achieves one-click game server deployment for users, replacing what might currently be a manual setup by staff. This gives users near-instant gratification – e.g., order a server, and within a minute or two (automated), it’s online and listed in their dashboard. That is a big step toward a cloud-like experience.

Web Hosting Provisioning (Nginx/PHP-FPM websites)

Web hosting typically means providing the user with space on a web server for their website (possibly with a control panel for things like domains, databases, email). We aim to automate creating a hosting account or website on our servers:

• Using an Open-Source Hosting Panel (ISPConfig or similar): One efficient strategy is to use an existing hosting control panel that supports automation:

  • ISPConfig 3: This is an open-source hosting panel that can manage multiple sites, FTP accounts, databases, and more on a LEMP stack. Crucially, ISPConfig has a Remote API (SOAP/REST) that allows creating websites, FTP users, databases, etc. via external calls​

    stackoverflow.com

    . There are functions like client_addSite, sites_web_domain_add, sites_database_add, etc., which can be invoked with parameters (domain name, quota, etc.). An example from documentation: “the function to add an FTP user is sites_ftp_user_add”​

    howtoforge.com

    , and similarly there are functions to add a website.

    • Implementation: We could set up ISPConfig on the web hosting server. When a user orders a web hosting plan, our portal calls the ISPConfig API:

      1. Create a “client” (account) in ISPConfig for that user if not exists.

      2. Create a “site” (vhost) with their domain, pointing to a directory, with PHP enabled (and any quotas as per plan).

      3. Create an FTP user for that site (so the user can upload files).

      4. Create a database if the plan includes one (and perhaps include phpMyAdmin on the server for them).

    • ISPConfig will handle the underlying Nginx config generation, PHP-FPM pool setup, Unix user management, etc. The portal just triggers it. This saves us from writing those deployment scripts from scratch.

    • Example: Using ISPConfig’s SOAP API in PHP might look like: $client->login($apiUser,$apiPass); $params = [...]; $client->sites_web_domain_add($session_id, $client_id, $params); (per API docs) which returns an ID or throws error. We should cite that one can script any available function in ISPConfig’s API​

      howtoforge.com

      ​

      howtoforge.com

      , giving us confidence we can automate website creation.

  • Alternatives:

    • Virtualmin (Webmin) is another OSS panel with an HTTP API/CLI. A command like virtualmin create-domain --domain example.com --pass [pass] --template "Default" could be executed from our server to create an account. We could SSH into the hosting server from the portal server with keys to run such commands.

    • CyberPanel (with OpenLiteSpeed) has an API, if the stack could be OpenLiteSpeed instead of Nginx.

    • cPanel/WHM is commercial but widely used. It has an API (XML-API or newer JSON API) that could create an account. If the company already had cPanel, integration is possible. However, cPanel licensing per account/server might not align with a small local provider’s budget, and it’s not mentioned in the current setup.

    • DirectAdmin is a cheaper commercial panel with a well-documented API; it could be considered if a robust panel is desired without cPanel’s cost.

    • Given we already have a “DIY” stack (Nginx/php-fpm on presumably Ubuntu), ISPConfig fits well as it supports Nginx and can be installed on Ubuntu, orchestrating exactly that environment.

• Custom Scripting (Ansible/Puppet/etc.): If using a panel is not desirable, we can automate via configuration management tools:

  • For example, write an Ansible playbook that creates a new *nix user, sets up directories, configures an Nginx site, and reloads Nginx. There are Ansible roles available for website provisioning. Our portal’s PHP could call shell_exec to run Ansible with the appropriate variables (domain, user, etc.), or use a tool like Ansible AWX (which provides an API to launch playbooks).

  • Another lightweight option is a Bash/PHP script on the webserver that the portal calls (via SSH or a simple internal HTTP endpoint) to do the setup. However, this requires careful security (e.g., allowing the portal machine to SSH as root to the hosting server with key-based auth and specific sudo privileges).

  • Given the complexity and risk of custom scripting, leveraging an established panel’s API (with its safety checks and structured approach) is attractive for reliability.

• Provisioning Steps in Practice: Suppose a user orders “Web Hosting Basic” with domain “example.com”:

  1. The portal collects the domain name (we may allow them to use a temporary domain or prompt them to update DNS).

  2. Portal calls ISPConfig API:

     • client_add (if new client) or find existing client record.

     • sites_web_domain_add with params like domain = example.com, hd_quota = e.g. 5GB, traffic_quota, PHP mode (PHP-FPM), etc., and link it to the client.

     • Capture the returned domain ID.

     • sites_web_domain_set_status to activate if needed (ISPConfig might create it active by default).

     • sites_ftp_user_add to create an FTP login for that domain (if user will upload via FTP).

     • Possibly sites_database_add to create a database and user.

  3. The user gets the info displayed in their dashboard (domain, FTP credentials, etc.). We would also email them these credentials securely.

  4. The website is now live on our server (likely serving a default placeholder page until user uploads content).

  • Note: DNS setup is out-of-scope of this portal, but we might advise the user to point their domain’s A record to our server IP. If we plan to offer domain registration later, that could be another integrated feature.

• Post-Provisioning Management: Through the portal, the user might want to perform some actions:

  • Change their FTP password – we’d call the API to update the ftp user.

  • Add a subdomain – API to add a new “Alias” or “Subdomain” entry.

  • Reconfigure PHP settings or enable features – advanced, but could be done via API or not exposed to user (fixed environment).

  • These can be gradually implemented. At first, we might simply show the info and instruct the user to contact support for changes not in the UI. Over time, we expose more controls as confidence in the automation grows.

• Resource Monitoring: We can integrate simple monitoring for web hosting accounts if needed (like disk usage). If using ISPConfig, the panel itself gathers some stats which we could fetch from the API or database. Alternatively, we run a cron job to record disk usage for each account and display that in the dashboard (not critical but a nice touch for transparency).

In essence, automation for web hosting will likely be handled by an existing panel’s remote API for reliability. This gives us a well-tested foundation to manage the Nginx and PHP configurations. The portal acts as a front-end to these API calls, presenting the user a simplified “dashboard” view of their site instead of the full panel (which might be overwhelming or not branded as our own). This achieves self-service account creation similar to how cloud providers let you create web app instances or how managed WordPress hosts provide one-click site setup.

VPS Provisioning (Virtual Private Servers on Ubuntu/KVM)

For VPS hosting, we need to automate the creation and management of virtual machines on our infrastructure:

• Hypervisor/Platform: Assuming the company uses KVM on Ubuntu (possibly managed via something like Proxmox VE or plain libvirt). The goal is to create a new VM with specified resources and an OS image, on demand.

• Proxmox VE API: A strong recommendation is to use Proxmox VE, which is an open-source virtualization management platform. If the company isn’t already using it, adopting Proxmox could greatly simplify automation:

  • Proxmox provides a web UI for admins, but importantly a full REST API. “Proxmox VE uses a REST like API… JSON as primary data format… the whole API is formally defined”​

    pve.proxmox.com

    . This API can do anything the UI can, like create VMs, config, start/stop, etc.

  • We can set up a template VM (or use cloud images) for common OS (e.g., an Ubuntu 22.04 cloud-init image). When a user orders a VPS, the portal calls Proxmox API POST /nodes/{node}/qemu (for KVM VM) with JSON data: VM ID, template to clone or ISO to install, CPU/RAM, disk size, network config (maybe assign an IP from a pool), and Cloud-Init settings for initial user credentials.

  • Proxmox API also handles LXC containers. If offering container-based VPS (for Linux only), those could be even faster to provision. But typically “VPS” implies full VMs, so we’ll assume KVM.

  • We’ll need to authenticate to Proxmox API (using an API Token or ticket – Proxmox supports API tokens with permissions​

    forum.proxmox.com

    ). The ConcreteCMS backend can store these credentials and use PHP cURL or a Proxmox PHP client library to call the API.

  • Creating a VM might take some seconds (especially if it has to copy a disk image). We can get a task ID from Proxmox and poll it. Once done, we can query the VM’s IP (if DHCP assigned) or assign a static IP as part of cloud-init network config.

• Libvirt/Terraform/Other Tools: If Proxmox is not used, alternatives:

  • Use libvirt directly (the library behind KVM/QEMU). We could use the PHP libvirt extension or call virsh commands via shell. However, managing storage pools, network, etc. via libvirt manually is quite complex to do correctly and safely from PHP.

  • Terraform with a libvirt provider: Terraform can be invoked to create a VM based on a plan. This is somewhat heavy but ensures idempotency. The portal could generate a small Terraform config and run it. Probably overkill here.

  • OpenStack or CloudStack: These are cloud orchestration platforms that sit on top of KVM. They have APIs (OpenStack’s OpenCloud API, etc.) and would provide a very AWS-like experience (multi-tenant, project quotas, etc.). However, they are big systems to deploy and maintain. For a smaller scale and given we only need basic VPS automation, Proxmox (which is much simpler to manage yet powerful) is a more pragmatic choice. OpenStack could be a long-term aspiration if the company’s infrastructure grows significantly (multiple compute nodes, self-service networking, etc.).

  • There’s also Apache CloudStack and OpenNebula which target small service providers, offering AWS-like features with simpler deployment than OpenStack. They might be worth R&D research but would significantly change how the current systems work. In contrast, Proxmox can be installed on the existing single node or cluster and co-exist with current KVM usage.

• Provisioning Workflow: When a user orders a VPS:

  1. The portal gathers required info: choose OS from a list (if we offer choices), perhaps hostname (or generate one), maybe SSH key (allow user to provide one for login).

  2. The order triggers the VM creation:

     • If Proxmox: call the create VM API with specs matching the package (CPU cores, RAM, disk). Inject cloud-init data (set the hostname, create a user/password or user/public-key for SSH). Reserve or pick an IP address for it (IP management could be a simple pool we maintain – possibly Proxmox can be told which IP or use DHCP).

     • The API returns a task ID. We wait for completion or periodically check (Proxmox’s API allows checking task status). Once done, VM is ready.

     • Start the VM (if not auto-started). Ensure it’s running and obtain its IP (if we have DHCP + DNS, maybe we can get it, or we pre-set static).

  3. Update our database with the new VPS details (VM ID, etc.) and mark it active for the user. Add the user to the “VPS Customers” group if not already.

  4. On the UI, the new VPS appears with status “running” and details.

• VM Management: Through the portal, we will implement controls:

  • Start/Stop/Restart: Portal calls Proxmox API (e.g., POST to /nodes/{node}/qemu/{vmid}/status/stop or /start). This returns quickly and we can update status.

  • Console Access: Proxmox provides a noVNC HTML5 console. We can either direct the user to Proxmox’s noVNC web console for their VM (which might require some kind of ticket or an API call to get a console URL). Another approach is to run our own noVNC connected to the VM’s VNC/spice, but leveraging Proxmox’s built-in is easier. Possibly, we can have an iframe or new window that loads a URL from Proxmox with an auth token (Proxmox API can issue a ticket that we attach to a web console URL).

  • Reinstallation/Rebuild: If the user wants to change OS or start fresh, we can either create a new VM and destroy old (if IP reassign is manageable) or use Proxmox’s ISO install via API. A simpler method is to treat it as a new order (the user would cancel one and order another). Rebuild could be a later enhancement.

  • Scaling/Resizing: Initially, packages are fixed. If later we want to let users upgrade (more RAM, etc.), this can be done via Proxmox API (changing RAM or adding CPU, though some changes need VM off). It would also involve a billing change. We can defer this until custom package options are offered.

  • Snapshots/Backups: We could allow users to take a snapshot (Proxmox API for snapshot) if their plan permits. Or schedule backups. This might be a premium feature in future.

• Tracking and Resource Management:

  • Ensure we don’t oversubscribe beyond capacity. Proxmox can show resource usage on the node. If we have one node, we might have to put checks like “if remaining RAM < needed, don’t allow new VPS and show out-of-stock message”. In cluster mode, we could pick a node with available capacity.

  • If IP addresses are limited, maintain a pool. Possibly integrate with the data center’s IPAM or simply a config file listing available IPs. When provisioning, assign one and mark it used. If a service is cancelled, release the IP.

  • These resource considerations are part of scaling up to a “cloud” – initially, manual oversight might suffice (e.g., admins add IPs to a list and the script picks the next free one).

In summary, VPS automation will be achieved by using a virtualization management API, with Proxmox VE being the prime candidate for ease of integration. Proxmox’s API is comprehensive and stable, with many client libraries (even a PHP library exists)​

pve.proxmox.com

. Using it, our portal can programmatically create VMs on the fly, very similar to how DigitalOcean or AWS would via their backends. This turns what might be a manual KVM creation process into a user-driven, instantaneous action – a huge value-add for the user experience.

By using these provisioning approaches for all services (AMP for games, ISPConfig for web, Proxmox for VPS), the portal’s backend effectively becomes an orchestrator that calls the right tool for the job. Each of these tools is either open-source or commercially supported, fitting the company’s preference to lean on existing solutions rather than building everything from scratch. It also means we inherit a lot of functionality (security, updates, etc.) from those platforms, focusing our development on integration and UI.

Billing and Zoho Invoice Integration

Automating billing is crucial for a self-service portal. The company uses Zoho Invoice (with API support), which we will integrate to handle invoicing, payment tracking, and potentially subscription management. Here’s the plan for billing integration:

• Zoho Customer Sync: When a user registers on the site (ConcreteCMS user), we will ensure they exist as a customer in Zoho Invoice. Zoho’s API allows creating and managing contacts (customers). We can use the user’s registration info to call POST /contacts to create a new contact in Zoho (or update if already exists). We’ll store the Zoho Contact ID associated with the Concrete user (perhaps in an extra field or a mapping table) so we know where to send invoices for that user. This happens behind the scenes on sign-up or first purchase.

• Product/Item Setup: In Zoho Invoice, one typically defines Items (products/services) that appear on invoices. We should set up items like “Game Server - Basic Plan”, “Web Hosting - Basic”, etc., each with a price. These can be configured in Zoho’s dashboard, or via API. Once set up, our portal just needs the Item IDs or names so it can create invoices referencing them. Alternatively, we can create custom line items on the fly via API, but having predefined items is cleaner.

• Creating Invoices via API: Zoho Invoice’s REST API is comprehensive: “The Zoho Invoice API allows you to perform all the operations that you do with our web client”​

  zoho.com

  . This includes creating invoices, retrieving them, and managing recurring profiles. When a user places an order for a service:

  • If it’s a recurring service (subscription) like monthly hosting, we will use Recurring Invoices. We call Zoho’s endpoint to create a recurring invoice profile for that customer, with the chosen item and price, and a billing interval (e.g., every 1 month). Zoho will then automatically generate invoices on schedule. The API for recurring invoices supports creation and also fetching the next occurrence, etc.​

    zoho.com

    .

  • If it’s a one-time charge (e.g., setup fee or a one-time product), we create a regular Invoice.

  • We can set the invoice to be sent automatically by Zoho (so the customer receives an email from Zoho with invoice link) or mark it to be handled manually. Likely we’ll have Zoho email it for convenience.

  • For the first payment, we might want immediate payment. Zoho Invoice can integrate with payment gateways (like Stripe, PayPal) so the invoice email has a “Pay Now” button. Alternatively, if using Zoho Checkout or Zoho Subscriptions, there are hosted payment pages. If the company prefers to take payment within our portal, we could integrate a payment gateway separately, but that complicates things. It might be simpler to rely on Zoho’s system initially.

• Payment Confirmation & Provisioning: Ideally, provisioning should happen after payment to avoid fraud or non-payments. Options:

  • Use webhooks: Zoho Invoice can send a webhook or callback when an invoice is paid. We can set up a listener in ConcreteCMS to receive these notifications (it would contain invoice ID, status paid). Upon receiving a payment confirmation, we trigger the provisioning (if not already done) or activate the service.

  • Polling: The portal could periodically call Zoho to check invoice status. This is less real-time and not ideal, but as a fallback or for simplicity we could, for example, check overnight for any unpaid invoices and send reminders or suspend if overdue.

  • Immediate provisioning strategy: Some hosts choose to provision immediately and trust the user to pay (especially if offering a trial or grace period). Given this is a small provider and likely will manually verify initial customers, we might provision on order and then chase payment. But as we automate, we likely want payment first for costlier resources (like VPS).

  • We can implement a toggle per product: for example, maybe allow instant setup for game servers (if low cost) with a short grace period, but require payment before VPS deployment (higher cost).

• Subscription Management: For ongoing services, Zoho will handle generating invoices every cycle. Our portal should:

  • Show the user what subscriptions they have (we can get recurring invoice profiles from Zoho via API, which include the recurrence frequency and next invoice date).

  • Option to cancel a subscription: If a user wants to cancel a service, we’ll provide a button that (after confirmation) uses Zoho’s API to stop the recurring invoice​

    zoho.com

    and mark the service for termination. We then also trigger de-provisioning (e.g., send API call to delete the VM or game server either immediately or at period end).

  • If a user upgrades/downgrades, that likely means canceling one subscription and creating a new one (or editing the recurring profile in Zoho and adjusting the service on our end).

• Billing UI in Dashboard: (As described in UX section) the Billing module will fetch data from Zoho to display:

  • List of invoices: We can call GET /invoices?customer_id=XYZ to get all invoices for that user. This returns invoice numbers, dates, status, amount, etc., which we display. We will cite that Zoho’s API is built on REST principles with predictable URLs, making it straightforward to integrate​

    zoho.com

    .

  • If the user clicks an invoice, we can either display the details from the API or redirect to the invoice’s link (Zoho provides a portal where customers can view their invoices online – each invoice has a permalink).

  • Payment status: if an invoice is unpaid and within our portal we want to facilitate payment, we could have a “Pay Now” that simply opens the Zoho payment page for that invoice (or re-sends the invoice email). In deeper integration, we might use Stripe API ourselves and then update Zoho via API to mark paid, but using Zoho’s flow is simpler and ensures no mismatches.

• Automation & Coordination: We will tie billing events to provisioning events:

  • New Order: Create recurring invoice (status “AutoSend” or draft), charge immediately if possible. After successful charge or if configured to auto-provision, create the service.

  • Invoice Overdue: If an invoice goes overdue X days, the portal could automatically suspend the service. E.g., call the game server stop API, or shut down the VPS. We would send warning emails before this (Zoho can also send payment reminders). If invoice gets paid, re-enable the service. This can be a cron job or triggered by Zoho webhook (Zoho might not have an “invoice overdue” webhook, but we can detect by due_date vs current date on our end).

  • Cancellation: When a user or admin cancels a service, end the recurring profile on Zoho to stop future billing, possibly issue a pro-rated final invoice if needed (Zoho might handle proration manually, so maybe not automate that).

  • Billing Cycles & Proration: Initially, keep it simple (monthly billing, alignment per service from the start date). As we scale, we might consider aligning all services to one billing date or offering credits, but Zoho Invoice can handle each recurring separately.

• Zoho API Tech Details: We’ll use Zoho’s v3 API. Authentication will be via OAuth token or Zoho’s authtoken system. Likely we’ll register our portal as a self-client in Zoho, get a refresh token and use it to call APIs server-to-server (Zoho’s API requires an access token in the header for each request). Our code needs to handle refreshing the token when expired. Security of these tokens is paramount (store in config not accessible publicly).

  • There are client libraries and examples. In fact, a guide demonstrates using a PHP SDK (nebkam/zoho-invoice-php) where after setup $client->createInvoice([...]) can be called​

    rollout.com

    ​

    rollout.com

    . Such libraries can simplify integration and we should consider using one to reduce boilerplate.

  • Zoho Invoice also allows Recurring Invoice creation via API easily (as seen in their docs, it’s just another endpoint with similar JSON structure except recurrence info)​

    zoho.com

    .

• Customer Portal: Zoho Invoice has an integrated customer portal feature where customers can log in to Zoho to see their invoices. We need to decide if we use that or keep everything in our portal:

  • If we fully integrate, the user shouldn’t need to use Zoho’s portal at all – they manage everything through our site.

  • If time is short, we might initially let advanced users use Zoho’s portal (for example, include a “Open Billing Portal” link). But ideally, we present the necessary info ourselves to keep the experience unified.

By automating billing through Zoho Invoice, we offload a lot of complexity: tax calculations, invoice formatting, payment processing can all be handled by Zoho’s platform while we just trigger events and sync data. The API gives us the flexibility to tie billing state to service state. This integration means the company’s accounting remains centralized in Zoho (which they already trust), and the portal just becomes a window to that data. The result is a smooth experience where a user can sign up, subscribe to a service, pay online, and have their service automatically deployed – with invoices and records properly logged in the back-office system.

Modular Dashboard and Future Expansion

The architecture and design choices above not only meet the current needs but are deliberately aimed at future expansion and maintainability. Here we highlight how this plan supports long-term growth and what tools/practices will help:

• Modularity & Maintainability: Each feature of the portal is encapsulated:

  • Frontend modules as web components mean we can add, remove, or update a section without affecting others. For example, if a new “Database Hosting” service is introduced (say, offering managed MySQL databases), we can create a <db-hosting-panel> component and corresponding backend API endpoints, without rewriting existing parts. The navigation can be updated to include it for users who have that service.

  • The use of web components (Lit) ensures a gradual upgrade path. As Lit’s documentation notes, you can upgrade one component at a time without a full rewrite​

    lit.dev

    . This is crucial for an evolving project – we might start with a basic version of the game panel and later replace it with a more sophisticated one; thanks to encapsulation, as long as the new component exposes similar interfaces to the rest of the app, it’s a drop-in replacement.

• User Group–Based Access: By leveraging ConcreteCMS user groups for permissions, we inherently design a system that’s extensible for different user roles and service combinations. Concrete allows creating new groups easily – if in future we have “Reseller” users or “Team Admin” vs “Team Member” distinctions, we can manage those with groups and adjust the UI accordingly (showing some features only to admins, etc.). This aligns with how cloud providers manage access (IAM roles, etc., though on a simpler scale for us). And as noted, hiding unauthorized features keeps the UI from exposing things incorrectly​

  docs-ospc.rackspace.com

  .

• Scalability of Infrastructure: The backend tools we chose (AMP, ISPConfig, Proxmox) all support scaling out:

  • AMP can manage multiple game servers across multiple host machines (with its ADS module controlling remote instances), so if game hosting grows, the same API calls just need a target parameter for which host, etc.

  • Proxmox is built for clustering; as the company adds servers, they can form a Proxmox cluster and our API calls can specify on which node to create a VM. Resource usage can be balanced or selected. We might extend the portal to show which datacenter or node the VPS is on if needed.

  • ISPConfig can also manage a multi-server setup (web, DB, DNS separate). If one day they have separate web hosting servers, ISPConfig API can create the site on a specific server if configured. This way, growth in user base and hardware can be handled without redesigning the portal – it would be more about configuration and perhaps extending our API integration to handle multiple endpoints.

  • The design assumes one environment (Prince George data center), but if the company ever offers services in another location, we could introduce a concept of regions (like “PG1” vs “City2”) and allow user to choose. The portal’s structure is already service-based, so adding a region filter is feasible when needed.

• Adding New Service Types: The cloud-style portal vision might include future offerings: e.g., domain registrations, SSL certificates, container services (Docker hosting), etc. Thanks to the micro-service architecture (not in the microservices sense, but micro frontend + dedicated backend logic per feature), we can incorporate these:

  • Each new service = new module + backend integration. We would follow the same pattern: find or build an automation tool for it, integrate via API, create UI component for management, and tie into billing.

  • For instance, if offering domain registration, we’d integrate with a domain registrar API (like Enom or Namecheap) for domain search/registration, and build a “Domains” component, and use Zoho to bill domain renewals annually.

  • The portal thus becomes a one-stop shop for all services, much like how AWS console keeps adding icons as they launch new services. Our scope is smaller, but approach similar.

• Use of Standard Protocols/APIs: All integrations are via well-defined APIs (REST/HTTP for AMP, Proxmox, Zoho, etc.). This means our portal is essentially orchestrating APIs. If any component (e.g., Zoho Invoice) were to be replaced (say the company moves to a different billing system later), we can swap out that integration module without overhauling the entire portal. The independence of each integration (billing, each service type) reduces coupling.

  • We will document the interfaces: e.g., what data does the front-end expect from the “list VPS” endpoint, what actions can it call. As long as future backends adhere to that, the front-end doesn’t need major changes.

• Tools & Libraries Recap (Tech Stack): Aligning with R&D goals:

  • Frontend: Lit for web components (with its small size and modern features), possibly combined with a UI component library (Shoelace) to accelerate development. This modern stack will be familiar to developers and ensure the portal looks up-to-date. Additionally, using modules and ES6, we can keep performance high (loading only what’s needed). If desired, we could also incorporate a state management library (like Redux or MobX) to manage global state (e.g., user info, theme) for the SPA, though it might be overkill initially.

  • Backend: ConcreteCMS (PHP) as the foundation gives a stable user & content management system. We will develop ConcreteCMS Packages or custom classes for our functionality, which is in line with Concrete’s extensibility. We might utilize some Concrete-specific features like the Job system to schedule tasks (for example, a Concrete Job to check for unpaid invoices daily). If any part of our integration needs background processing, we can use Concrete’s queued jobs or even integrate Laravel’s Queue since Concrete9 can pull in such packages.

  • APIs & Automation Tools:

    • Game: CubeCoders AMP (commercial, enterprise features)​

      discourse.cubecoders.com

      with its API, or Pterodactyl (open-source, API-rich) as an alternative​

      spigotmc.org

      .

    • Web: ISPConfig (open-source, well-documented API) for web hosting automation​

      howtoforge.com

      , or a configuration management approach with Ansible (open-source) if we go custom.

    • VPS: Proxmox VE (open-source, robust API + UI) for VM orchestration​

      pve.proxmox.com

      , which aligns well with running on Ubuntu and can integrate Ceph or ZFS for storage as needed. It also has a community and support if needed.

    • Billing: Zoho Invoice SaaS (with free/paid tiers) – we stick with it to not reinvent billing. Possibly consider Zoho Subscriptions in the future if automatic recurring credit card charges are needed (Zoho Invoice mainly handles invoice-based billing; Zoho Subscriptions is another Zoho product for subscription management with card charging). But Zoho Invoice is sufficient for sending recurring invoices and tracking payments for now.

  • These tools collectively give the company a pseudo-”cloud stack” using mostly open-source components: ConcreteCMS + custom code (portal UI), Proxmox (virtualization), ISPConfig (hosting), AMP (games), and Zoho Invoice (billing). Each is chosen for being scriptable and integrable into a unified system.

• Testing and Quality: Because the portal will orchestrate critical operations (like creating/deleting servers, charging money), thorough testing is needed:

  • Use a staging environment with dummy accounts and maybe a Zoho sandbox to simulate the flows (Zoho provides a sandbox mode or one could use a separate organization for testing).

  • Test each service provision end-to-end (e.g., create a VPS via API and ensure it comes online accessible, create a game server and verify it runs).

  • Implement logging on the backend for all API calls (so admins can trace what happened if something fails: e.g., log “Provision VPS: API payload/response” securely).

  • Plan fallback strategies: if an automation fails (say VM creation fails because of no resources), the system should catch that, not charge the user (or issue refund), and notify an admin to intervene. This kind of robustness will come from building in checks and using the responses from our automation APIs.

• Security Considerations:

  • The portal should enforce SSL (which it will, since Concrete site likely runs HTTPS).

  • API credentials (for AMP, Proxmox, Zoho, etc.) are stored server-side and never exposed to clients. The front-end only communicates with our backend endpoints.

  • We’ll use Concrete’s permission model to ensure one user cannot ever act on another’s resources by crafting IDs in requests, etc. (The backend will always check that the resource (server ID, etc.) belongs to the logged-in user before executing an action).

  • Rate limiting might be considered to prevent abuse (e.g., don’t let user spam create VM calls – though they’d need to pay each time, but for free trials it could be an issue).

  • Regular updates of the underlying systems (ConcreteCMS, etc.) to get security patches.

In conclusion, this plan delivers a comprehensive, modern dashboard solution that meets the current needs and sets the stage for future developments. By studying how big providers do it and using a combination of web components, RESTful integration, and proven automation platforms, the company can offer its customers a cloud-like experience on a local infrastructure. Users will be able to sign up, see only what they should, launch services on their own, and manage their account – all through a cohesive interface. Meanwhile, the company can streamline operations, as the portal ties together billing and technical provisioning (reducing manual work).

The use of mostly open-source or existing solutions also aligns with the company’s R&D ethos, allowing them to innovate on top of solid foundations rather than building everything from ground zero. Over time, this portal can expand with new features (from advanced monitoring to maybe a mobile app interface) by following the scalable architecture we’ve chosen. It’s a developer-centric approach that will appeal to the target user base and grow with the company’s ambitions.

Sources:

• DigitalOcean – example of developer-focused dashboard design​

  digitalocean.com

• Rackspace Cloud Panel – unified interface and permission-based feature visibility​

  docs-ospc.rackspace.com

  ​

  docs-ospc.rackspace.com

• Dashboard UX best practices – emphasize modular design for maintainability​

  niamh-oshea.medium.com

• Lit Web Components – benefits of standard web components in any environment​

  lit.dev

  ​

  lit.dev

• CubeCoders AMP – supports extensive API control for game server automation​

  spigotmc.org

• Proxmox VE – provides a full REST API for VM management (JSON-based)​

  pve.proxmox.com

• Zoho Invoice API – fully covers operations (invoices, customers, recurring profiles) via REST​

  zoho.com

  ​

  zoho.com

• ConcreteCMS 9 – includes a built-in REST API for integration and headless use​

  concretecms.com

• ISPConfig – example of remote API usage for automating hosting tasks (adding FTP user)​

  howtoforge.com