Frequently asked questions about Joy Services products, infrastructure, billing, and support

Use the Sign Up page to register your account, complete any required verification steps, and then log in to the customer portal. Depending on the service type, additional business or identity verification may be required before certain products are activated.

Yes. If your workflow supports multiple projects, teams, or departments, it is recommended to separate access logically for operational clarity, internal auditing, and permission control. For agencies or resellers, separate credentials or sub-accounts may be preferable.

If MFA is available in the portal, it should be enabled for every administrative user. MFA significantly reduces the risk of unauthorized access and is strongly recommended for any account that manages infrastructure, billing, or API credentials.

Use the password recovery flow on the login page. If you are unable to recover access, contact support and be prepared to complete verification steps so ownership can be confirmed before any account recovery action is taken.

Create a new credential first, update your applications or automation to use the new token, confirm successful operation, and only then revoke the old token. This avoids downtime and keeps your integrations stable during the change.

Where multi-user access is supported, separate user access is preferred instead of shared credentials. This improves accountability, logging, and security, especially for operations, support, and billing teams.

Yes, in most cases account contact information can be updated, but sensitive changes may require verification. This is done to prevent unauthorized ownership changes or social engineering attempts.

Accounts may be reviewed for fraud prevention, compliance checks, abuse history, payment verification, or unusual order patterns. These checks help protect the network and reduce platform misuse.

Depending on the service, region, or order risk profile, we may request phone verification, business information, government-issued identification, or proof of address before activation or expansion of service limits.

If role-based access is available, it should be used to separate technical, billing, and administrative privileges. Least-privilege access reduces risk and prevents accidental operational changes.

Available payment methods vary by region, product, and account type. Standard plans may support online payment methods, while enterprise customers may be eligible for invoice-based billing or bank transfer upon approval.

Most self-service products are prepaid. Some enterprise or contract-based services may operate under invoice or postpaid billing arrangements depending on commercial approval and service scope.

Many services renew automatically unless cancelled before the renewal date. Customers should always review billing settings, renewal dates, and product-specific terms in the portal.

If payment fails, the service may enter a grace period depending on the product. Continued non-payment may result in suspension, restricted access, and eventual termination, which can also affect stored data and reserved resources.

In most cases yes, subject to technical constraints, plan eligibility, and available capacity. Some changes may apply immediately, while others may require scheduling, reconfiguration, or migration.

Yes, business customers can generally obtain invoices, billing records, and account transaction details. Enterprise invoice workflows may include PO references, billing contacts, and taxation details where applicable.

Yes, most services can be cancelled before the next billing cycle. It is your responsibility to cancel before renewal if you do not want charges to continue automatically.

Setup fees, activation charges, provisioning fees, and one-time engineering costs are generally non-refundable unless explicitly stated otherwise in the order or applicable policy.

Applicable taxes such as GST, VAT, or similar jurisdictional charges may be added depending on your billing country, entity type, and tax treatment. Customers are responsible for providing accurate billing details.

Yes. For large deployments, network services, DDoS protection, private infrastructure, or multi-site needs, custom quotes can be prepared based on technical scope, commercial terms, and expected usage.

Most instances are provisioned within minutes, depending on image readiness, regional capacity, storage initialization, and any verification requirements tied to the account or order.

Yes. Reinstallation is typically available from the portal. You should always back up any important data before starting a reinstall because the process may replace the existing operating system and local storage contents.

Where the platform supports ISO mounting or custom image workflows, you may be able to deploy using your own media. If self-service ISO is not available for your plan, support can advise on available onboarding options.

The underlying platform may vary by region, cluster, or service line. Infrastructure choices are made to balance performance, stability, operational consistency, and predictable customer experience.

Most public cloud instances include at least one public IP unless the service is designed for private networking only. Additional IP resources may be available based on need, justification, and availability.

If the relevant region or location is offered on your product line, you may select it during deployment or through a custom order. Availability depends on stock, service type, and regional deployment policy.

Yes, subject to product and licensing availability. Linux images are generally common, and Windows-based offerings may be available under eligible plans or custom enterprise arrangements.

In many cases yes. Some changes can be applied through a resize workflow, while others may require instance restart, storage expansion, or migration depending on the architecture.

Yes, public addressing is typically static for many services, though the exact behavior depends on the product line. If address persistence is critical for your application, confirm the service behavior before relying on it operationally.

Yes, provided usage complies with applicable policies, licensing requirements, and all laws. Customers are responsible for ensuring that software use, data handling, and workload behavior remain compliant.

Infrastructure planning is designed around service reliability and predictable performance. Actual contention and resource-sharing behavior vary by platform design, but the goal is stable operational performance under expected workloads.

In some cases, yes. This depends on the software vendor’s licensing terms, the technical deployment model, and whether the platform supports customer-provided licensing under the applicable product.

Allowed workloads depend on the plan, service policy, and abuse risk profile. Game servers, streaming services, and high-traffic applications may be allowed on suitable plans if they comply with network and acceptable use policies.

You should first check portal status, power state, recent maintenance notices, firewall settings, and networking configuration. If the problem persists, open a support ticket with timestamps, recent changes, and any console or error output.

Where console or rescue access is supported, it can be used for troubleshooting boot issues, firewall lockouts, and misconfiguration recovery. Availability depends on the product and virtualization layer.

Availability depends on your selected product line. Hosting options may include standard web hosting, managed application hosting, or infrastructure where you manage the application stack directly.

Yes. WordPress can run on standard hosting environments or self-managed cloud instances. Performance and security depend on the stack, caching, plugin quality, and update discipline.

Control panel availability varies by service line. Some plans may include panel access, while others may support it as an optional or custom add-on.

In many hosting configurations yes, subject to plan limits, control panel features, DNS setup, and resource allocation.

Depending on the platform, you may use Let’s Encrypt, upload your own certificates, or request managed assistance. Renewal responsibility depends on how the certificate is deployed and managed.

Email hosting may be available as a separate product or bundled solution depending on the service. Deliverability depends on correct DNS setup, reputation, and mail authentication standards.

Yes, guidance may be available depending on the service scope. These records are important for reducing spoofing, improving deliverability, and aligning email authentication policies.

Domain registration availability depends on the product offering. If not provided directly, you can still use external registrars and point DNS or hosting to the relevant Joy Services endpoint.

Yes, migration assistance may be possible depending on the project size, source platform, and complexity. Website files, databases, mail, DNS, and SSL may all need to be planned carefully during migration.

Performance issues may be caused by application design, database queries, PHP configuration, image size, lack of caching, DNS resolution, origin response time, or external scripts. A proper diagnosis should isolate the bottleneck before changes are made.

Yes, where the plan includes S3-compatible storage. Customers can generally use standard APIs, SDKs, and access-key-based authentication with supported endpoints.

Snapshots are commonly available for supported services. Snapshot availability, retention, and frequency depend on the product line and the storage architecture behind the instance.

Not always. Some plans include backup capability, while others offer it as an optional service. Customers should always verify backup scope, restore method, and retention period before assuming coverage exists.

Retention periods vary by plan and service type. Some services may keep short rolling backup windows, while others support longer retention or policy-based archival depending on the product.

That depends on whether a valid backup or snapshot exists and whether restoration is supported for the deleted resource state. Customers should not assume deleted resources can always be recovered.

Data may remain available for a limited retention period depending on policy and service type, after which it may be permanently deleted. You should export all critical data before cancellation or termination.

Object storage is designed for object access patterns, not as a direct replacement for local block storage. While gateway or filesystem tools may exist, behavior and performance differ from native disk volumes.

Versioning support depends on the product feature set. If versioning is required for your workflow, confirm this before designing your storage policy around it.

That depends on how the backup service is implemented. Customers should understand whether backups are local, cluster-based, remote, immutable, or policy-managed before relying on them for disaster recovery.

No infrastructure provider can guarantee zero data loss across all failure scenarios. Customers handling important or regulated data should maintain their own tested backup and recovery procedures.

Yes, where offered by the selected plan or service line. CDN use cases may include static content delivery, media acceleration, cache distribution, and edge-based performance improvement.

Typical setup involves pointing a domain or subdomain to the assigned endpoint, configuring the origin, setting cache rules, and ensuring TLS and DNS are correct. The exact workflow depends on the product interface.

Cache misses can be caused by response headers, bypass rules, cookie behavior, query strings, origin directives, or recent purges. Cache logic should be reviewed step by step before assuming the CDN is failing.

DNS hosting may be available for authoritative zones, record management, and routing-related functions depending on the service line. Feature depth varies by platform.

Propagation speed depends on TTL values, resolver behavior, and cached results across the internet. Even when a change is applied immediately at the authoritative source, external resolution may still vary temporarily.

In many cases yes. Customers may use platform-issued certificates, Let’s Encrypt, or custom certificates depending on service support and operational preference.

Advanced caching behavior may be available depending on the product design. Customers should confirm rule support before planning complex origin or cache-control logic.

Performance depends on edge presence, routing behavior, ISP paths, origin placement, congestion, and cache efficiency. A global performance issue should be analyzed by region rather than treated as one single cause.

Purge capability depends on the product. Where available, customers can usually clear cached content by path, hostname, or a broader invalidation method depending on the feature set.

This is commonly possible either through the application, CDN rules, or the hosting layer. The correct place to enforce it depends on the architecture and desired cache behavior.

Coverage depends on the plan and service architecture. Protection may include common Layer 3 and Layer 4 flood patterns and, in some cases, additional Layer 7 handling where the service is designed for application-aware mitigation.

No provider can responsibly guarantee prevention of all attack types and all attack sizes in every circumstance. The objective is to reduce impact, improve resilience, and restore service availability as effectively as possible.

In extreme cases, temporary null-routing may be used to protect broader network stability, contain collateral impact, or preserve upstream integrity. This is usually treated as a last-resort control measure.

Open a ticket immediately and include the target IP or hostname, timestamps, affected protocols or ports, traffic characteristics, and any supporting logs or packet captures if available.

Additional processing, filtering, or path steering can introduce some overhead depending on architecture and attack conditions. The exact impact depends on how the mitigation is applied and where the traffic is processed.

This depends on the product and mitigation profile. Real-time services often require careful balancing of latency, filtering strictness, and false-positive control.

Depending on the service, customers may be able to control local firewalling or submit rule requirements. Some managed mitigation layers may also support profile-based customization.

Any mitigation system must balance detection and continuity. While the goal is to protect legitimate traffic, false positives can occur, especially during complex or high-intensity attack scenarios.

The answer depends on the plan. Some services focus mainly on network-layer mitigation, while others may include or support application-layer controls for HTTP and related workloads.

Only if you have explicit written authorization and the test is properly coordinated. Unauthorized traffic testing that resembles attack activity may be treated as abuse and handled accordingly.

Yes, on eligible services. Customers typically need their own ASN, authorized IP resources, and proper routing documentation such as IRR or RPKI readiness depending on the use case.

Typical requirements include ASN, peering location, desired port speed, IPv4 and IPv6 details, technical contacts, NOC information, traffic expectations, and any special routing requirements.

Yes. Prefix filtering may include prefix-length restrictions, max-prefix thresholds, route validation behavior, documented authorization requirements, and other operational safety controls.

Only when you have explicit authority and the necessary documentation. Unauthorized announcements are prohibited and may result in immediate session shutdown and abuse handling.

Where supported, communities may be used for traffic engineering, signaling, or blackhole-related control. The exact community set and behavior depend on the network design and service scope.

Yes, where the relevant service and location support IPv6. Customers should confirm dual-stack readiness and routing policy expectations before activation.

Repeated instability can affect platform and peer health. We may apply controls, request corrective action, or suspend the session until the cause is resolved.

Where supported, blackhole signaling may be available as part of routing policy or mitigation operations. This must be used carefully and according to network policy.

Requirements vary by product and operational policy, but proper route authorization is strongly encouraged and may be mandatory depending on the service.

Yes, for supported engagements. Activation support may include technical coordination, IP details, session review, policy alignment, and route-filter readiness.

Yes, where offered commercially and technically. Transit solutions may vary by location, capacity, handoff design, and operational requirements.

This depends on the facility, service model, and commercial arrangement. Dedicated handoff, port-based service, or private interconnect may be possible for eligible customers.

Anycast-related solutions may be available depending on the service line and intended use case, especially for DNS, CDN, security, or distributed edge workloads.

Multi-site announcements may be possible if the service, routing policy, and technical design support it. Proper engineering and route-consistency planning are important before deployment.

Internet routing is dynamic and may change due to policy, upstream preference, peering conditions, or mitigation actions. Routing should be investigated with looking glasses, traceroutes, BGP tables, and timing context before conclusions are drawn.

Use the support section in the customer portal and provide clear reproduction steps, timestamps, affected services, screenshots, logs, and any recent configuration changes. Good technical detail speeds up resolution.

Support coverage depends on the plan. Some products are handled on standard operational schedules, while enterprise customers may have priority or 24/7 support terms based on contract.

Yes. Some maintenance is scheduled for upgrades, patching, network work, or capacity changes. Emergency maintenance may also occur when required for stability or security.

Yes, depending on the service and project scope. Migration planning may include data transfer, DNS changes, application cutover, routing, storage movement, or workload replatforming.

Response time depends on plan, issue severity, and current operational conditions. Critical incidents are prioritized based on impact and urgency.

Where applicable, material incidents and planned maintenance may be communicated through a status page, portal notices, or direct communication channels.

In many cases yes, particularly for enterprise or change-managed work. Availability depends on staffing, scope, lead time, and operational risk.

Include affected service identifiers, exact error messages, source and destination details, timestamps, recent changes, logs, screenshots, and what troubleshooting you already performed. This reduces back-and-forth and speeds diagnosis.

Support may help investigate service-impacting issues to the extent allowed by visibility, product scope, and plan terms. Some deeper investigations may be best-effort or enterprise-scoped.

That depends on whether the service is self-managed, partially managed, or fully managed. Customers should not assume system administration is included unless explicitly stated.

Platform monitoring may exist for infrastructure health, but workload-level monitoring is not automatically guaranteed. Customers should deploy their own monitoring for applications, services, and business-critical functions.

Emergency maintenance may be performed with limited notice where necessary to address security risk, hardware faults, routing issues, abuse impact, or urgent service stability concerns.

Yes, subject to engagement scope. High availability design may involve multiple regions, storage replication, failover logic, CDN, DNS strategy, or routing-level resilience depending on your workload.

Basic onboarding guidance may be available for supported services. Larger customers may also require planning sessions for network setup, migration sequence, or operational workflow.

Use the portal or official support contact method associated with your plan and include your account or service identifier so the issue can be routed correctly and quickly.

Your Terms of Service page sets the legal framework for use of the platform, including acceptable use, billing, operational controls, and service responsibilities. Customers should review it before deploying production workloads.

Yes. The Privacy Policy explains how operational data, account information, logs, and related data are handled. Customers should read it carefully if they process regulated or personal information.

Support for compliance-related needs depends on the product, contract scope, technical controls, and the specific requirement involved. Customers remain responsible for ensuring their own legal and regulatory fit.

Yes. We may restrict, suspend, or remove access to content or services where required by law, court order, security necessity, or material platform risk.

Proxy services may be available as a product, but their use must comply fully with policy, applicable law, and any product-specific restrictions. Abuse, evasion, or unlawful use is prohibited.

Operational logs may be retained for security, troubleshooting, fraud prevention, abuse investigation, performance analysis, and legal or compliance reasons depending on the service.

Resale may be possible depending on the product and commercial agreement. Resellers remain responsible for downstream use, customer conduct, and policy compliance unless otherwise agreed in writing.

White-label or partner-style offerings may be possible for selected products or commercial arrangements. Technical and operational limits still apply even where the commercial presentation differs.

Yes. Policies may be updated to reflect legal changes, operational requirements, security developments, or product evolution. Continued use of services generally indicates acceptance of the latest published version.

Use the official support or policy contact channel listed in your portal, service page, or legal documents, and include enough account context so the question can be reviewed properly.