Recommended FTP and SFTP client software for Spark Rack services

Recommended FTP and SFTP client software for Spark Rack services is a practical Spark Rack customer guide about FTP, FTPS, SFTP, file clients, permissions, transfers, archives, and deployment. It is written for readers who may not administer servers every day, but who still need enough detail to understand what a setting or error means, make a safe change, verify the result, and know when the problem must be escalated.

Use the exact values displayed for the selected account, domain, mailbox, database, or hosting service. Hostnames, usernames, ports, paths, limits, and available controls can differ by product. Never substitute a value copied from another service merely because the labels look similar.

Recommended choices

How to choose

Use FileZilla when several operating systems must follow the same instructions. Use WinSCP for Windows users who need synchronized folders, an integrated editor, or scripted transfers. Use Cyberduck when a simple bookmark-oriented interface is preferred on macOS or Windows. All three can be appropriate; the decisive requirement is support for the exact protocol shown in ECP.

Security requirements

• Prefer SFTP or FTP over TLS when the selected service provides it.
• Download only from the official project or an official operating-system store.
• Review the host-key or certificate prompt instead of permanently accepting an unexplained mismatch.
• Do not save production passwords on a shared or unmanaged computer.
• Remove obsolete saved sites and credentials after a project ends.

Start with the correct service and evidence

In ECP, begin in Services, FTP users, file access, web roots, logs, and the selected transfer client. Record the current value before changing it. A useful troubleshooting record separates what is known from what is assumed and preserves the exact timestamp of every test.

When Spark Rack support can help

Contact support when the ECP connection values are missing, the service rejects known-correct credentials, a provider-managed port or certificate is incorrect, or the same failure occurs in more than one properly configured client. Include the application name, operating system, exact server and port without the password, timestamp, full error text, and the relevant connection log.

Reference checklist

• Confirm protocol, hostname, port, username, and remote starting path from ECP.
• Read the client log from the first connection line through the failure.
• Check whether the operation fails for every file or only one path.
• Avoid changing permissions broadly until ownership and the intended web path are confirmed.
• Also consider whether the wrong protocol or port is selected.
• Also consider whether a local firewall or NAT blocks the data connection.
• Also consider whether credentials or starting path are wrong.

Security and change-control notes

Use a unique credential for each service identity, store it in an approved password manager, and remove access when a person or vendor no longer needs it. Before editing production data or configuration, keep a restorable copy and a record of the original value. Do not expose passwords, private keys, payment data, recovery codes, or full database contents in screenshots or normal support messages.

After the task is complete, verify renewal dates, notification recipients, and dependent services. Many recurring problems are caused by a technically correct change that was never updated in a second client, application configuration file, DNS provider, forwarding rule, scheduled task, or external integration.

Extended diagnostic sequence

1. Confirm scope: one user, one device, one network, one domain, one mailbox, one database, one service, or all customers.
2. Record the last known-good time and every relevant change after it.
3. Check account and service lifecycle status, billing status, permissions, and notices.
4. Test the most direct supported connection without optional plugins, proxies, caches, or integrations.
5. Compare the working and failing paths one variable at a time.
6. Preserve exact logs and responses before clearing caches or resetting credentials.
7. Restore the last known-good value when the failure began immediately after a reversible change.
8. Retest from an independent client or network and observe for delayed processing.
9. Document the final cause and remove temporary workarounds.

Controlled comparison matrix

When the first test does not identify the cause, compare the result across a small matrix instead of making another configuration change. Test the same account or resource from a second device, then test a second known-good account or resource from the original device. When possible, repeat the test on another network. This separates account-specific, service-specific, client-specific, and network-specific failures.

Record each result before continuing. A two-minute comparison often provides more useful evidence than repeatedly resetting passwords, recreating records, changing permissions, or reinstalling software.