Taking your replies to comments into account, I'll try to provide an answer here.
For clarification, OP has a webservice handing out signed JSON Web Tokens and is worried about the security of his/her private key on the server. OP asked, whether encoding it is any good, answer to that is no. Encodings do not provide any security, as they are reversible without a key. If an attacker gains access to your encoded private key, there is nothing preventing him from decoding it.
Furthermore, OP asked, whether bcrypt is a secure way of storing the private key. Answer is also no. bcrypt is not an encoding or encryption function, but a cryptographic hash function. It takes an input and generates a secure salted cryptographic hash, which allows the server to compare it to other inputs and decide, whether both input are the same (i.e. matching a user's password while logging in, without having to store the password in plain text).
Hashing your private key renders it unusable, as it cannot be recovered and the hash cannot be used to sign or decrypt any messages.
Maybe you can store your private key in a file, only readable by the web server user (i.e. www-data, when using apache) or use other. However, if your cannot even trust your own server to this extend, maybe that's the point to start considering more security measures. Eventually you have to trust something.
Edit: OP indicated, that only the server is interested in the JWT itself, rendering signature verification by the user obsolete. In this case, the server can either generate a keypair just for itself, which seems like an overkill, if the signing and verifying server is always the same machine.
Considering that having one secret is sufficient for OP, HMAC or a similar key-based hash function might be a better choice here. The server has a secret key, which is used to create a hash of the JWT and verify it upon receiving the token from a user. Tampering is prevented by this technique.
An asymmetric approach might be better, if there is a single server/(micro-)service creating those tokens and other endpoints require the JWT signatures to be verified. An advantage is, that the "Token Factory" can be an even better protected machine/service, while regular endpoints only need the corresponding public key, thus not comprimising the keypair, if hacked.